[UPHPU] OOP continued

Mac Newbold 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 
should have.

> 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 mailing list