problems are obvious in retrospect - writing OO being an example

[lawrence]

I asked a lot of questions in May about how to organize OO code. I
didn't get great answers here, but someone here suggested that I look
the Eclipse library, which was a good tip. Looking at its small,
simply objects was an education for me.

What I was wondering, when I rewrote my cms from procedural code to OO
was how to avoid end up have every class called by ever other? I was
writing massive objects where every object needed every other object.
It was a mess.

In the end, I realized that the objects I was writing were too big.
Again, looking at the Eclipse library brought this home to me. What I
learned can be distilled to this:

Write pebbles, not boulders. Small objects, not big objects.

Eventually I feel like I finally "got" OOPs programming: that portion
of my objects that did not need some other object then became the base
class that other classes were built on. For instance, the portion of
my forms class that didn't need any other class became my base forms
class. But then where I needed the $sql database class to get info to
fill out some forms, I created a child class of forms, and the child
combined the database class with the base forms class.

It's all obvious in retrospect, but it was opaque to me back in May.

I write this as a lesson for others struggling with the same issue I
struggled with.

[John Heim]

[email]lkrubner@geocities.com[/email] (lawrence) wrote in

> Eventually I feel like I finally "got" OOPs programming: that portion
> of my objects that did not need some other object then became the base
> class that other classes were built on. For instance, the portion of
> my forms class that didn't need any other class became my base forms
> class. But then where I needed the $sql database class to get info to
> fill out some forms, I created a child class of forms, and the child
> combined the database class with the base forms class.
>

What do you mean "combined"?

class database extends forms?

[Zurab Davitiani]

brian wrote on Wednesday 20 August 2003 13:12:

> [email]lkrubner@geocities.com[/email] idiotically stated:
>

>> I write this as a lesson for others struggling with the same issue I
>> struggled with.

>
> Then would you say, at some point, OO just isn't the right solution for
> some
> projects? From what you said, it seems that to finally write "good" OO,
> it just got insanely encapsulated to a point that going back to procedural
> php is just simpler and easier.
>

Few years back I wrote down some thoughts about OO and software development.
Maybe it's relevant here and maybe some would like to read it. I never
actually acted on those opinions because of lack of time on my hands.

[url]http://www.welikeyou.com/pide/process-based-ide.html[/url]

In short, I don't see OO as well-suited for most software development;
instead, I think development should be based on processes.

--
Business Web Solutions
ActiveLink, LLC
[url]www.active-link.com/intranet/[/url]

[matty]

brian wrote:

> [email]lkrubner@geocities.com[/email] idiotically stated:
>

>> I write this as a lesson for others struggling with the same issue I
>> struggled with.

>
> Then would you say, at some point, OO just isn't the right solution for
> some
> projects? From what you said, it seems that to finally write "good" OO,
> it just got insanely encapsulated to a point that going back to procedural
> php is just simpler and easier.
>

Personally I think OO php works well if you have a largely hierarchical class
structure, with simpler classes aggregated into larger ones, to hide functionality,
data, etc as per "The One True Way (tm)" - if you can do
$Admin->ValidateDdata();
and the $Admin object will call member objects, or use other classes transparently
to its caller, that's great; if everything is calling everything else in some
kind of byzantine spider web, it's probably not a great design, or something that
could be done better in some other language...

[Bruno Desthuilliers]

lawrence wrote:

> I asked a lot of questions in May about how to organize OO code. I
> didn't get great answers here,

<comp-object>'here' meaning c.l.php</comp-object>

You'd probably have more answers on an OO ng, like comp.object, but
would it have help you much at that point ? Some concept are better
learned by experience, and basics of code structure - be it procedural,
functional or OO - is one of them IMHO.

> but someone here suggested that I look
> the Eclipse library, which was a good tip. Looking at its small,
> simply objects was an education for me.

Yep, good working exemples are a great help.

> What I was wondering, when I rewrote my cms from procedural code to OO
> was how to avoid end up have every class called by ever other? I was
> writing massive objects where every object needed every other object.
> It was a mess.

Indeed...

> In the end, I realized that the objects I was writing were too big.
> Again, looking at the Eclipse library brought this home to me. What I
> learned can be distilled to this:
>
> Write pebbles, not boulders. Small objects, not big objects.

Right. Absolutely. Or, to be more accurate : dont make object biggers
than they should be to be cohesive - but not smaller.

Note that this principle may also apply to functions/methods, and even
whole programs !-)

> Eventually I feel like I finally "got" OOPs programming:

You are a very happy man !

I started learning programming with OO languages, almost always tried to
favor the OO approach (even if not always applied it), and I still
wouldn't claim I 'got' OOP. Yes, I believed I had once I understood the
very basic concepts of classes, instances and inheritence. But there's
much more to OO than just using classes and inheritence.

> that portion
> of my objects that did not need some other object then became the base
> class that other classes were built on.

Woop. They're one thing clear in this, it's that you (re)discovered some
principles of dependency manangement. But the end of the sentence is not
quite clear to me. Could you elaborate ?

> For instance, the portion of
> my forms class that didn't need any other class became my base forms
> class.

Well... The base 'form' class should be the one factoring common
behaviours and attributes of all 'form' classes (and still this may be a
pretty simple-minded approach). The fact that the base 'form' class
depends on others or not has nothing to do with it.

May I give you an advice ? Read about some basic OO concepts - like for
exemple the Dependency Inversion Principle (but there are some others,
and they all work together...).

> But then where I needed the $sql database class to get info to
> fill out some forms, I created a child class of forms, and the child
> combined the database class with the base forms class.

How did you 'combined' two classes, in a language that don't allow
multiple inheritence ? By composition ?

Well, this all seems a bit OT here, so crosspost and fu2 comp.object

Bruno

[Bruno Desthuilliers]

brian wrote:

> [email]lkrubner@geocities.com[/email] idiotically stated:
>
>

>>I write this as a lesson for others struggling with the same issue I
>>struggled with.

>
>
> Then would you say, at some point, OO just isn't the right solution for some
> projects? From what you said, it seems that to finally write "good" OO, it
> just got insanely encapsulated to a point that going back to procedural php
> is just simpler and easier.
>

OO main goal is not IMHO to reduce complexity, but to help manage it by
reducing dependencies. And writing 'good' OO code is not necessarily
'insanely encapsulating' all and everything - which is just that :
insane-, but more about capturing the invariant and hiding the rest in
the right place.

Now I agree that some things may be better done in good ole procedural
code !-)

Bruno

[John Heim]

Zurab Davitiani <agt@mindless.com> wrote in

> Few years back I wrote down some thoughts about OO and software
> development. Maybe it's relevant here and maybe some would like to
> read it. I never actually acted on those opinions because of lack of
> time on my hands.

You argue that just because there are objects in the real world, we
shouldn't be tied to them in programming. But an "object" in a program
isn't real. It's a logical construct. And the analogy to objects in the
real world is just that -- an analogy, nothing more.

They could have chosen a different analogy. Heck, they could have
called them "virtuals" or "dreams" instead of "objects". We'd have
"Dream Oriented Programming", DOP instead of OOP. And where would your
argument be then?

You also failed to explain how your idea of process oriented
programming has advantages over OOP. And how does it address the real
programming problems OOP was invented to address.

For instance, you give a good example of how an object might be built
to deal with converting variables of different types to strings. If you
looked at that as a process, what advantages would be gained.

[matty]

Jochen Buennagel wrote:

> matty wrote:

>> ... if everything is calling everything else in some
>> kind of byzantine spider web, it's probably not a great design, or
>> something that could be done better in some other language...

>
> Doesn't mean that it would be any better in another language.
>

I didn't say it would be! ;p The point was more, that if you
*have* to jump through ridiculous hoops to implement it in PHP
*because of the language*, it might be better to do it in something
else.

You normally can do it OK in PHP, but there do seem to be cases where
it's a bit artificial

[John Heim]

matty <matt+nntp@askmenoquestions.co.uk> wrote in news:3zR0b.9737

> You normally can do it OK in PHP, but there do seem to be cases where
> it's a bit artificial

I don't know... I'm kind of skeptical. Are you saying php's object
implementation is lacking when compared to other OOP languages or that
OOP is not a panacea?

Well, I'm kind of skeptical either way. I guess there are some minor
things about the way objects are implemented in php that are a
hinderance. Perl has that really cool hash thing going where objects
are essentially overloaded associative arrays. But , I dunno... php
seems alreight to me. If I had to say which OOP implementation was
better I'd be hard pressed.

And I wouldn't *really* say OOP is the answer to *ALL* programming
problems but I find it hard to believe there are many real world
situations where it would be a hinderance. It's almost inconceivable
because an object can be nothing more than a group of variables and
functions -- related or not. Which is really what a traditional program
is anyway. You could just write your constructor function like you
would main () of your C program.

class doEveryThing
{
function findACureForCancer () { ...}

function balanceFederalBudget () { ... }

function endWorldHunger () { ...}

function doEveryThing ()
{
findACureForCancer ();
balanceFederalBudget ();
endWorldHunger ();
}
} # ssalc


$happiness = new doEverything ();

[matty]

John Heim wrote:

> I don't know... I'm kind of skeptical. Are you saying php's object
> implementation is lacking when compared to other OOP languages or that
> OOP is not a panacea?

Well, it is actually lacking compared with Java (or Perl even for that
matter), but that doesn't stop PHP being an excellent platform for
web applications. Continually-running processes in Perl/Java can have
the edge sometimes, but yes, I think PHP is brilliant. (Perl does
have speed advantages sometimes though)

Certainly, the PHP5 OO sounds like it addresses most of the issues I
have with PHP's OO as it stands.

>
> And I wouldn't *really* say OOP is the answer to *ALL* programming
> problems but I find it hard to believe there are many real world
> situations where it would be a hinderance. It's almost inconceivable

Me neither. (Although there are times when speed considerations win out,
but those are "border" cases). I was more posting a hypothetical scenario -
given that a system is written in an OO manner, it may be the case that
PHP's incomplete OO support forces various kludges to keep the code OO. I've
yet to find a scenario like this, and most of the bad php OO stuff I've seen
out there is down to the coder, not the system requirements.

[Jochen Buennagel]

matty wrote:

> ... if everything is calling everything else in some
> kind of byzantine spider web, it's probably not a great design, or something that
> could be done better in some other language...

Doesn't mean that it would be any better in another language.

Martin Fowler has written a great book on the subject: "Refactoring -
Improving the Design of Existing Code"

If you apply the advice from that book to your code and go through with
it, I think that any "spider web" can be transformed into a nicely
structured and layered OO application - without ever being in a state
where it doesn't run.

Jochen

--
/**
* @author Jochen Buennagel <zang at buennagel dot com>
*/

[lawrence]

John Heim <johnheim@nospam.tds.net> wrote in message news:<Xns93DD99F867AA5gargerywiscedu@144.92.9.81>. ..

> [email]lkrubner@geocities.com[/email] (lawrence) wrote in

> > Eventually I feel like I finally "got" OOPs programming: that portion
> > of my objects that did not need some other object then became the base
> > class that other classes were built on. For instance, the portion of
> > my forms class that didn't need any other class became my base forms
> > class. But then where I needed the $sql database class to get info to
> > fill out some forms, I created a child class of forms, and the child
> > combined the database class with the base forms class.
> >

> What do you mean "combined"?
>
> class database extends forms?

Yes, till I read the book "Effective Java". It is a book full of
advice that can be applied to any OO language. One of their chapters
is "Favor composition over inheritance." My new approach is that I
only use inheritance for "interfaces", and I use composition for all
else. (Of course interfaces don't really exist yet, but I write base
classes with no implementation, which should be pretty easy to make
into real interfaces once my company feels comfortable writing to PHP
5.)

--Lawrence Krubner
[url]www.krubner.com[/url]