[UPHPU] OOP continued
mac at macnewbold.com
Wed Jun 29 16:00:43 MDT 2005
Today at 3:30pm, Jacob Wright said:
> This is true too. Obviously you wouldn't use OOP if the language didn't
> support it. And OOP design is still usable as you said.
There are even languages that _do_ support OOP, and certain projects,
where doing OOP for that project in that language would be a bad idea.
Poor support for OOP, or even the wrong support for OOP for a particular
purpose, can be about the same as none at all sometimes.
> Another obvious one is the issue of time. Many employers, customers,
>> users, (I'll lump them together as the Boss here), don't really care about
>> many of the benefits that OOP can provide. They just aren't benefits that
>> they value. In those cases, the costs of using OOP (I'm mostly thinking
>> added development time here, but there are others) just aren't justified
>> by the value the Boss places on them. (I'm not saying OOP is always
>> necessarily slower to plan, develop, and debug than procedural. But it
>> does tend to be so. The code is usually larger, which leads to more bugs,
>> and can be harder to plan and understand than "normal" code.) Many times
>> the Boss doesn't care about "reuse" and "encapsulation", he cares about
>> how costly it will be to develop and maintain.
> Here I have to say that in my experience (which I know is probably different
> than in yours), OOP has been much easier to maintain and more cost
> effective. That was with developers who wrote OOP properly of course (no
> huge inheritance trees, not breaking objects up into smaller objects just
> because they could, etc.).
Yes, maintenance can be very easy in OOP, and thus very cost-effective.
Many of the projects I have worked on require little or no maintenance at
all, once they are working and debugged in the first place. They don't
evolve or change, they just keep doing what their doing, year after year.
So a client doesn't want to pay up front to get cheaper maintenance if
nobody is expecting much maintenance anyway.
>> One of the places OOP
>> shines is when you're building components that will be used over and over
>> again. They have a higher up-front cost in exchange for lower cost every
>> time they're reused. Many times there won't be a second time that the
>> class is used. It has exactly one purpose, and the higher up-front cost
>> isn't worth it.
> This is true, sort of. The more reusable you try and make something, the
> higher the up-front cost (even with procedural). But if you just make an
> object for a particular project only (which is often the case with things
> that won't be reused) it won't have a high up-front cost.
I agree with you that this can be true for both procedural and OOP. Part
of the higher up front cost I'm talking about with OOP is not just
building it for reuse, but building it at all. OOP requires class
declarations, and methods, and usually comes with public this and private
that and getters and setters, et cetera and so forth. Much of the extra
code that comes with OOP can be eliminated, simplified, etc. by using
procedural instead, lowering the up front cost.
>> One that isn't so obvious and is often underutilized is the matter of the
>> programmer or development team, and their familiarity and skill with OOP.
>> Simply put, if they're not good with OOP, it can be easy to eliminate all
>> the benefits of OOP by doing it very wrong. If they're good at procedural,
>> but not OOP, there's the cost of the learning curve to consider. If
>> they're good at procedural, and know how to think and code modularly, they
>> can still achieve many of the same things that OOP can do.
> Again, your bad past experiences with those who don't know OOP but use it
> anyway shines through. And I agree. Even "experienced" developers, meaning
> they've been in the field along time, don't necessarily write the best code.
Absolutely. Experience is no substitute for skill. :)
>> It usually takes a really big project to need more than a handful of
> true, and a handful or less of classes are easily maintained and created
> just as a handful of functions are.
For the most part, yes, but even due to the larger volume of code (even
slightly larger) that it takes to accomplish the same thing in OOP instead
of procedural code, it can make a difference in how much effort it takes
to create and maintain. But I think you're right, good code done either
way is probably very similar in maintenance costs.
> I agree and am glad you shared with us. And probably the thing to note is
> that you shouldn't just write classes because OOP will benefit you. You
> should use OO design and theory to do your projects. If you just write
> classes to write classes, you will make a mess. If you write them
> understanding how objects ought to work together, you will then reap the
> benefits of OOP. (note: don't let that dissuade you from diving in and
> learning OOP. Just don't use it on important projects, ie. paying projects
> ;), that others may have to work with until you have a better
Right. Don't use it for the sake of using it. And by all means, don't try
and force classes on a non-object-oriented design. Use it when it makes
sense. I'll even make an absolute statement out of that:
*Always* use OOP when it makes sense.
Mac Newbold MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com http://www.macnewbold.com/
More information about the UPHPU