Re: Re: poor Perl OO design hinders maintenance effectiveness..

Tell me about it, I've recently had to work with code where object constructors call completely unrelated methods instead of just creating the object. Some people just get carried away an make every damn thing an object. Nested objects also made the OO code completely un resuable and meant debugging had to drill down through each nested object.

There is no point in OO if you don't use it so you can reap the benefits. Everyone should be taught how to use a gun before they fire it.

Comment on Re: Re: poor Perl OO design hinders maintenance effectiveness..

Replies are listed 'Best First'.
Re: Re: Re: poor Perl OO design hinders maintenance effectiveness.. by pdcawley (Hermit) on May 01, 2002 at 08:17 UTC
There's nothing wrong with making everything into an object, in fact there's a lot to be said for it. I've found that most maintainance headaches have arisen when the code is some bastardized mixture of OO and procedural code. I'm not sure what you mean by 'nested objects'. If you mean using delegation then I have to disagree, delegation is often a great way of getting well factored loosely coupled code with a minimum of dependencies. If you're talking about deep inheritance hierarchies (complete with the added fun of multiple inheritance) then yes, you have to be bloody careful with it. The thing about OO is that you have to do it wholeheartedly OO code can look somewhat... 'diffuse' to someone who is used to the procedural way of doing things and it can be hard to see where stuff actually gets done, but careful method naming combined with well 'composed' methods alleviate that. Especially when you've got a test suite to look at too...	[reply]

Replies are listed 'Best First'.

Re: Re: Re: poor Perl OO design hinders maintenance effectiveness..
by pdcawley (Hermit) on May 01, 2002 at 08:17 UTC

I'm not sure what you mean by 'nested objects'. If you mean using delegation then I have to disagree, delegation is often a great way of getting well factored loosely coupled code with a minimum of dependencies. If you're talking about deep inheritance hierarchies (complete with the added fun of multiple inheritance) then yes, you have to be bloody careful with it.

The thing about OO is that you have to do it wholeheartedly OO code can look somewhat... 'diffuse' to someone who is used to the procedural way of doing things and it can be hard to see where stuff actually gets done, but careful method naming combined with well 'composed' methods alleviate that. Especially when you've got a test suite to look at too...

[reply]