[UPHPU] OOP continued
mac at macnewbold.com
Wed Jun 29 14:46:30 MDT 2005
Today at 1:54pm, Jeffrey Moss said:
> Sorry, I have to say it. Y'all just don't understand OOP (I know you hate
> that). If you understood it better you'd agree with me.
Um, no. Quit talking smack, and start being rational. Insulting people's
intelligence is just not going to get you anywhere. I understand OO and
OOP just fine, and 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
> Everything should be an object. Files should be objects. Drivers should
> be objects. Applications should be objects.
While it is fine and dandy that any of those things _can_ be
conceptualized as objects, if that's what floats your boat, that doesn't
mean it's the right way to program them. There are a lot of things that
just don't jive well with objects, or that would take significantly more
time/effort/code/pain to program as objects than in a simple, straight
forward procedural way. There is a big difference, as others have already
pointed out, between Object Oriented Design/Thinking and Object Oriented
Perhaps at this point, some elaboration is in order. If we all agree that
Objects are Good, then why am I speaking out against using them
everywhere? Because different projects have different goals, requirements,
criteria, and considerations, and Objects don't always fit into that.
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. The easy answer then is that OOP isn't the
right way to program that project. OO Design can still be used, and a
modular programming style can still give you many of the OOP benefits
without actually being OOP code.
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. 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.
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.
I'm sure that if we want to continue this, we could compile quite a list
of reasons why people don't use OOP for this project or that project. I'll
leave that as an exercise to the readers.
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.
> If everything was an object the world would be a much more interoperable
> place. :)
OOP isn't about interoperability. Maybe it is _you_ that doesn't
understand it very well. Interoperability is about the interactions
between two different systems, not the internals of a single system. OOP
is a programming/design methodology used inside a single system. While you
_can_ make Object-Oriented protocols/interfaces/etc. for interoperability,
Object-Oriented Programming is at a different level than interoperability.
OOP is about the guts of your implementation, inside your system, and
other systems just plain don't interact with other systems at that level.
You don't see or interact directly with the source code or internal
objects of another system.
Another soap box I should hop onto for a second, while I'm going is that
even in the cases where OOP is good, overuse of OOP is really really bad.
It usually takes a really big project to need more than a handful of
classes. 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.
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.
Mac Newbold MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com http://www.macnewbold.com/
More information about the UPHPU