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

Max Kanat-Alexander maxka at cats.ucsc.edu
Wed Nov 20 13:57:01 CST 2002


--
[ Picked text/plain from multipart/alternative ]
[LONG]
At 11:20 AM 11/20/2002, Steve Lewis wrote:
>Consider, the CSS classes used should belong to the object's class as
>well to achieve 'total' encapsulation.

         Only if you're /trying/ to combine content and presentation.
Encapsulation only applies on a certain level. In the case of web
development, encapsulation applies to the content data. I don't see why I
can't generally keep my CSS separate. (Unless I'm mis-understanding your
statement.)
         Even in application development, encapsulation only goes so far.
If I write a program that has a GUI, in Java, it will /look/ different on
most platforms (different fonts, etc) but will contain the same data.

>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.

         That is quite true. I can see where I might start having to resort
to Javascript or some server-side scripting to generate my CSS. Of course,
as long as I can keep that in a separate file, I've still /pretty much/
separated content and presentation; I have, however, in that case turned
presentation into a coding exercise, which is something to generally avoid.

>Articles may have many different pieces:
>[snip]
>Did you put enough CSS classes in there or are you
>going back and modifying your class?

         Well, now you're just encountering the limitations of CSS. I'll
agree with you there -- in any project, it's impossible to predict every
way that anything might go. That's always been my motto in application
design -- "You have _no idea_ what this code is going to be doing in a few
months."

>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?

         You're certainly hitting me over the head with the fact that I
should have mentioned an XML solution. :-)

>[snip]
>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?  [snip]

         XML doesn't have a terrible overhead, provided it's well-designed.
(I can see where the overhead would be greater than traditional overhead in
current RBDMSes, though.) Also, serialization is a decision that you make
yourself, depending on the project. Hopefully, you have some system (like
CF MX or something even better) that can serialize and deserialize XML
nicely. Or, you make a system.

>My point is that OO Design (particularly encapsulation) seems to create
>a paradox or two for the web developer.  [snip]

         Now isn't that the truth. When I first started making pages, I was
pretty shocked at how "undeveloped" the web-coding paradigm was. (Of
course, now I realize: A language that is basic and allows errors will draw
a larger audience than a strict language.)

         The basic problem we run into is that HTML isn't a programming
language in the _fullest_ sense. We have ways of interacting with HTML
/through/ other programming languages (such as the DOM), but it itself is
just markup. Because HTML doesn't have a strictly defined structure, and it
is SO dependent upon the User Agent, it's pretty difficult to act upon it
with traditional programming concepts.

         This is, of course, one of the things that widespread adoption of
XML and XSLT will hopefully change.

         -Max
--




More information about the thelist mailing list