Why OO? WAS Re: [thelist] php design question

Steve Lewis slewis at macrovista.net
Wed Nov 20 13:13:01 CST 2002


Max Kanat-Alexander wrote:

>>how can you embrace encapsulation while embracing the principle of
>>separation of content and display?

>          The best way? Make objects that generate HTML with CSS classes.
> Instead of setting style="color: red" on the inside of your object, set
> class="redObject" (or hopefully some other, better, more descriptive class
> name.)
Consider, the CSS classes used should belong to the object's class as
well to achieve 'total' encapsulation.  You should know the rules and
understand the rules before you break the rules.  The CSS classes do
manipulate objects of that class.  Also consider the potential for
bloating your stylesheet and HTML.  In some cases having predefined CSS
classes for everything may be good enough.  In some cases it will not.

Regarless of where you put the CSS classes, consider the object we are
working with is an article.  Articles may have many different pieces:
title, author, print and web publication dates, source (for syndicated
content), abstract...  You may need many css classes to display that
object correctly.  Do you trust that you can predict (when you write the
class) all the ways someone may want to manipulate this object's
display?  What do you do when a marketing type comes and says they need
to add an image right-aligned over here, or when they want to use an
oversize illuminated character in the first word of the first paragraph,
or every paragraph?  Did you put enough CSS classes in there or are you
going back and modifying your class?

When you are given the task of outputing the article in RTF what will
you do?  Write it out then use a HTML-to-RTF tool or modify your class?
   When you modify your class you will need to be careful of
side-effects.  You will also find that before long your class has become
too large to manage, with too many similar output methods all right next
to each other.  This makes the class more difficult to maintain and to use.

I was actually expecting someone to suggest the class outputs XML which
is transformed by XSLT.  Some of the same issues apply, some don't.  We
are stil left with the question of how to serialize the data of an
object for storage (usually in a DB).  Again, you may depend on XML.
Now what sort of overhead are you adding by doing that?  Other questions
need be answered.  This can go on.

My point is that OO Design (particularly encapsulation) seems to create
a paradox or two for the web developer.  These (competing) needs can be
balanced, but in a large project (where OO really shines in the
traditional-application world) those paradoxes can come back to haunt a
project, and have led some web projects to failure.

Understand, there are good uses for classes in web applications, and
they tend to be areas where a data structure is heavily manipulated and
will never live in a DB (such as shopping carts).  I am also, a fan of
OO Design in traditional applications.  Paul's example of the hardware
store is a good example of the value of OO, but for whatever reason his
procedural counter-argument was a bit weak.  You will need to decide for
yourselves whether the value of the OO Design in calculating pricing is
enough to overcome the other problems you might encounter on that road.

--Steve




More information about the thelist mailing list