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]

lk******@geocit ies.com (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?

[matty]

brian wrote:

lk******@geocit ies.com 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...

[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: "Refactorin g -
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>
*/

[Zurab Davitiani]

brian wrote on Wednesday 20 August 2003 13:12:

lk******@geocit ies.com 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.

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

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
www.active-link.com/intranet/

[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

[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:

lk******@geocit ies.com 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 <ag*@mindless.c om> 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.

[John Heim]

matty <ma*******@askm enoquestions.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 findACureForCan cer () { ...}

function balanceFederalB udget () { ... }

function endWorldHunger () { ...}

function doEveryThing ()
{
findACureForCan cer ();
balanceFederalB udget ();
endWorldHunger ();
}
} # ssalc
$happiness = new doEverything ();