[UPHPU] OOP continued

Jeffrey Moss jeff at opendbms.com
Wed Jun 29 15:57:37 MDT 2005

Whats all this my experience your experience crap? I'm right, you're all 
wrong, that's the end of it!


----- Original Message ----- 
From: "Jacob Wright" <jacwright at gmail.com>
To: "Mac Newbold" <mac at macnewbold.com>
Cc: <uphpu at uphpu.org>
Sent: Wednesday, June 29, 2005 3:30 PM
Subject: Re: [UPHPU] OOP continued

> I _know_ that there are many times where a more
> procedural style of code is much more appropriate than OOP. Especially
> the way some people do OOP, by making 2x-10x more objects than they really
> should have.

Had bad experiences with that? :) Bad OOP is usually worse than bad

> There is a big difference, as others have already
> pointed out, between Object Oriented Design/Thinking and Object Oriented
> Programming.

This is true.

One of the most obvious ones is the language issue. For one good reason or
> another, a project may need to be done in a particular language, which may
> not have good support for OOP.

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.

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
becuase they could, etc.).

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.

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.

People, don't forget that OOP is not the only source of good code. Being
> modular doesn't require OOP. Good code reuse doesn't require OOP. Even
> encapsulation doesn't require OOP (for example, in PHP, functions give you
> encapsulation by default, and there are similar things in many other
> languages). You don't have to use OOP to divide your code properly into
> multiple files, or make proper use of libraries or included files.

Yes, so true. There is some great procedural code out there. And OOP
principles/design will help with any type of project.

overuse of OOP is really really bad.


It usually takes a really big project to need more than a handful of
> classes.

true, and a handful or less of classes are easily maintained and created
just as a handful of functions are.

Many OOP programmers, especially less experienced ones or ones
> who don't know how/when to use good procedural code, tend to may way too
> many classes. That practice is very detrimental and harmful to the
> developer/team, the project, and the budget.

This is very true. Once again, less experienced developers making bad code
will hurt any project.

I don't mean to be insensitive or not nice, but I can't stand idly by
> while people mistakenly advocate unbridled use of OOP. Like almost every
> good thing, it should be taken in moderation, and in certain situations,
> not at all.

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



UPHPU mailing list
UPHPU at uphpu.org
IRC: #uphpu on irc.freenode.net 

More information about the UPHPU mailing list