How to make OO code not bloated in PHP?

[nuncanada]

Quoting Selkirk in another thread:

My working definition for bloated in PHP is:

Loads code that does not get used, loads data that does not get accessed, or performs calculations that do not contribute to the final product while servicing common or simple requests.

One of the main concepts of OO programming is the coupling of the data with its procedures.

The question is how can we be able to create OO applications in PHP without them being bloated (comments are a secondary problem imo)?

I see two options:

1) Use some persistency layer (ala SRM). Which introduces further problems as can be seen in http://php.weblogs.com/discuss/msgReader$2677

2) Invent some crazy way of converting classes and methods into procedural code during deployment

Any other way?

[Selkirk]

Off the top of my head...

• Write small methods that do only one thing.
• Write small classes that encapsulate only one concept.
• Combine your small classes with small methods in interesting ways.
• Use the decorator pattern to implement rarely used functionality.
• Use the visitor pattern to implement uncommon functionality.
• Avoid deep inheritance hierarchies.
• Split up large classes based on usage patterns. (for example, File becomes FileWriter and FileReader)
• For rarely used classes, REQUIRE files with class definitions just before you actually instantiate the class instead of at the top of the file.

Only one of these is specific to PHP...

[Stefano F.]

2) Invent some crazy way of converting classes and methods into procedural code during deployment

Then why not immediately code the PP way?

IMHO, the most sensible approach is to follow the advise of Selkirk: good design.

[Dr Livingston]

Reading Thinking In Java the author suggests early on that it is in some cases a better idea to implement Composition rather than Inheritance.

But again, this falls into the Good Design category I suppose ?

[Stefano F.]

Reading Thinking In Java the author suggests early on that it is in some cases a better idea to implement Composition rather than Inheritance.

Correct you are. The Gang of Four suggests a few strategies for creating good object-oriented designs. In particular, they suggest the following:

• Design to interfaces.
• Favor composition over inheritance.
• Find what varies and encapsulate it.

...

[Dr Livingston]

[Off Topic]

On this point of Good Design I saw a link over at javaworld.com leading to an article that suggests Setters and Getters are pure and utter evil.

Not actually read the article since I disagree with this point very strongly although I'd be interested in knowing what alternative the article author(s) have to offer ?

Maybe worth a look huh ?

[HogMan]

[Off Topic]

On this point of Good Design I saw a link over at javaworld.com leading to an article that suggests Setters and Getters are pure and utter evil.

Not actually read the article since I disagree with this point very strongly although I'd be interested in knowing what alternative the article author(s) have to offer ?

Maybe worth a look huh ?

Just finished reading it. Its interesting at the end of the article how he talks about the design process and how most getters/setters could be avoided. I would be interested in hearing some others thoughts on this. The article is here.

[lastcraft]

Hi.

Lot's of setters and getters are usually a sign that the data is too far away from the methods that use it. Objects should supply services rather than just data.

yours, Marcus

[lastcraft]

...which is just what the article says . Ok, next time maybe I'll actually read stuff before posting (although why change the habit of a life time).

yours, Marcus

[Dr Livingston]

Still to read the said article [will go off and read it just now] although having briefly in the past read about services this could prove to be a solution although at the time I saw this as just another layer that could have been avoided ?

Umm... I'm going to read that article now just so I know a bit more

Still not happy though; We do need those Setters and Getters

[ZangBunny]

I know PHP programmers that automatically write a getter and a setter whenever they define a class variable. phpEdit even has a keyboard template that does it automatically for you. Others hold that you should even use accessors inside the class exclusively.

I don't do that. I try to hold off writing accessors until it becomes truly necessary. Also, universal accessors like

function &get($name) {return $this->$name;} 

are almost as bad as making fields public, maybe even worse.

That being said, I really think discussions on good OO are very worthwhile, but considering this is a PHP forum, I see far too many references to Java sites for my taste. I know and agree that some of the best OO books use Java for their examples, but this forum being what it is i think we should more address the special requirements of our language of choice, PHP.

I sometimes envy the complex beauty of J2EE's object Ikebana. Martin Fowler's refactoring Iai-Do does wonders for slicing up classes in ever more finely grained fragments. The Gang of Four's structural Origami smites me with awe.

BUT when I put all those wonderful concepts and put them in a PHP application, I cry bitter tears when the garbage collection comes and tears it all down after every single page. (And my clients kill me because their nice new dedicated server takes over a second to serve a page.)

So yes, I think the discussion about bloat is valid and necessary and should not be seen in the light of "pure" OO and Java practices, but with special attentions to the special needs of PHP and the applications that we build with it. Lose those J2EE bookmarks and get a copy of Fowler's PoEAA, which is much more suited to our tasks IMHO.

[lastcraft]

Hi...

Lose those J2EE bookmarks and get a copy of Fowler's PoEAA, which is much more suited to our tasks IMHO.

Doesn't that use Java ?

Good design is good design though, it is just that Java has been the lingua franca for a while in the same way C used to be and good design books have to be as technology neutral as possible. Things are fragmenting now, with C#, Python and Ruby appearing in text so maybe we will get a PHP one once we get to PHP5.

Probably not a good one first off though.

Just to be contrary though, when I first start putting things together I do end up with many getters (not usually setters). Whilst the design is in flux you find that there are too many connections, but hey, it's early days. Then, as things start to take shape and data moves around, the accessors disappear and things tighten up. At least that's my experience. A better OO modeller would probably get more stuff right on the first go.

yours, Marcus.

p.s. The reason for the editing of this. Anybody using CRC cards? We have had several goes with it (some successful), but have fallen back to the whiteboard and test first (stub first) design.

[Dr Livingston]

... I know and agree that some of the best OO books use Java for their examples ...

Not only examples, but in regards to proper OO implementation and design, Java is the number one language to demonstrate proper OO.

Some folks would proberly disagree and go off and say we have C++ although remember C was not originally designed around OO - Java was. We also have .NET but IMO so what ?

.NET didn't kick off OO did it ? No, it was smalltalk, and yes folks, Java is wholly based around that language isn't it not ?

Java is referred to a lot in many ways for demonstrating proper OO and let's all be grateful that we have at least one source that we can all depend on, regardless of what other language we all use huh ?

[Dr Livingston]

Anybody using CRC cards?

Nope Still using Flowcharts and Structured English...

A lot simpler and less time consuming IMO...

Wouldn't mind though actually finding the time to pick up UML properly ?

Not from an educated background that is one skill that would look good in my CV

[Selkirk]

Anybody using CRC cards? We have had several goes with it (some successful), but have fallen back to the whiteboard and test first (stub first) design.

I've tried using them, and have also found a whiteboard to be the handier tool. At the time, though, I had a large two sided printing whiteboard.

[Selkirk]

Not only examples, but in regards to proper OO implementation and design, Java is the number one language to demonstrate proper OO.

Java has certainly taken the spotlight as the lingua franca of software engineering texts.

.NET didn't kick off OO did it ? No, it was smalltalk, and yes folks, Java is wholly based around that language isn't it not ?

Actually, Simula was the language that kicked off OO in the late sixties. Smalltalk came later in the seventies. I wouldn't say that Java is based around smalltalk any more than PHP is. Smalltalk might be considered more of a "pure" object oriented language than Java. Objective C is a more direct descendent of smalltalk. Wouldn't Java be considered more a descendent of C++? C++ seemed to have won the battle between objective C and C++ for an OO extension to the C language (the lingua franca of procedural programming?).

Interestingly, SmallTalk and Objective C are both dynamically typed as it PHP. C++ and Java are both statically typed.

C++ and Objective C compared

Objective-C offers runtime binding. C++ tries to fake it with mix-in classes and virtual functions, but after using runtime binding, I find that C++ is a frustrating language

It seems like the people who try dynamic typing seem to prefer it and find it more productive.

Objective-C: the More Flexible C++

It is a surprising fact that anyone studying GNUstep or the Cocoa Framework will notice they are nearly identical to the NEXTSTEP APIs that were defined ten years ago. A decade is an eternity in the software industry. If the framework (and its programming language--Objective C) came through untouched these past ten years, there must be something special about it.

Python & Java: Side by Side

A programmer can be significantly more productive in Python than in Java. How much more productive? The most widely accepted estimate is 5-10 times. On the basis of my own personal experience with the two languages, I agree with this estimate.

Now that computers have become fast enough that OO business programming languages can shed the yoke of memory management, perhaps the time has come for the dominant language to shed the yoke of restrictive type systems?

Ruby versus Smalltalk versus Objective-C versus C++ versus Java versus Python versus CLOS versus Perl5

[been]

Very interesting links Selkirk (again ), thanks!

Just wanted to top this off with a nice Smalltalk bumper sticker:

Java: The elegance of C++ with the sheer speed of Smalltalk

[Dr Livingston]

Actually, Simula was the language that kicked off OO in the late sixties.

Wasn't aware of that Thanks for clearing that up though;

Smalltalk might be considered more of a "pure" object oriented language than Java.

Sort of what I was attempting to put across I think ?

Not to sure of Phython myself ? Just how popular is this language and it's area of use I wonder... ?

My view of Java is biased in some cases though I still think that using Java as a basis to script PHP OO is a good thing ?

After all Sun Microsys. is now putting more effort into the Java language it's self now.

[lastcraft]

Hi.

As far as I remember (I am too lazy to google) the Java runtime was most influenced by Oberon and the syntax chosen to steal developers from C++. Instead it seems to have put a pretty big nail into the smalltalk coffin because Sun simply gives it away to developers.

I still have a soft spot for Java because I remember life before. The mainstream OO language was C++, which is actually two languages when you want to do anything really flexible. The phrase "language lawyer" comes from this stable.

Java also gave the mainstream a very network aware language, a very secure runtime and some good solid libraries (anyone remember MFC before then?). It is going to be front of the pack for tool and library support for some time to come.

It is also very readable in books. More so than Python or Ruby I feel.

yours, Marcus

[Dr Livingston]

Java also gave the mainstream a very network aware language, a very secure runtime and some good solid libraries (anyone remember MFC before then?). It is going to be front of the pack for tool and library support for some time to come.

Thank God for that IMO I agree with you on this point

As for book readablity I'm not so sure myself since I'm still trying to get my head around some of Java's syntax and it's way of doing things

Maybe I'm just thick aye ?

[Taoism]

p.s. The reason for the editing of this. Anybody using CRC cards? We have had several goes with it (some successful), but have fallen back to the whiteboard and test first (stub first) design.

I tend to jot stuff onto a notepad first, then fire up Visio and use it to help think things through. However, where I work the project requirements tend to change so fast that after about 5 goes at changing the Visio diagrams within a 2 week period I start to fall back into an iterative coding approach. I code, almost get the damn stuff working, then a client comes buy with "oh yeah, we scrapped all those business rules... here is a new set - can we get this by tomorrow?" bleh..

Fortunately not all our projects are like that. The ones I start by myself for new Intranet modules, etc tend to be a lot more organized (since I actually take the time to decide what I want)

One nice technique I have learned from using Fusebox so long is to use Wireframes if the client is willing to participate. It certainly helps the client get a feel for how the flow of the app will work.

Cheers,
Keith.

[lastcraft]

Hi.

One nice technique I have learned from using Fusebox so long is to use Wireframes if the client is willing to participate. It certainly helps the client get a feel for how the flow of the app will work.

Can you explain what the Wireframes are? I really have no idea of how fusebox works or really what it is. I am just curious.

yours., Marcus

[Dr Livingston]

Wireframes ? I breifly saw a diagram on this a while back and from what I seen I can only describe it as a more complex form of flow charts/diagrams ?

More geared towards program function and flow rather than program analysis though...

[firepages]

"Good design is good design though?"

design a sports car then implement it on a farm , conversely , a tractor on the raceway and you see where that logic can breakdown
(OK I personally see PHP as turbocharged ATV with bond like detatchable wings and a snorkel but you get my point).

PHP is not compiled .

if thats a bad thing then go JAVA or C++ , C# etc , compile your python scripts .. whatever.

"BUT when I put all those wonderful concepts and put them in a PHP application, I cry bitter tears when the garbage collection comes and tears it all down after every single page. (And my clients kill me because their nice new dedicated server takes over a second to serve a page.)"

at last the light ! , PHP is an interpreted scripting language , its not compiled , its not JAVA , half of JAVA's life is concerned with not upsetting the compiler , the other half making code reusable as its a pain to get that far in the first place , the third half is how long it takes to compile to byte-code and then `interpret`

however clever/useful/whatever many of the design patterns and methodologies that stem from JAVA or its ancestors& clones are , their usefulness often does not translate to an interpreted scripting language like PHP when utilised at runtime as is the case for the products of most of the readership here.
When utilising PHP for other tasks , GUI's or script generators etc then its a different story (to a point)

the OOP discussions in this forum are interesting , informative and often a peep into the minds of some severly clever people and a mindgrind for OOP muppets like me.

But , when in the next thread we see , "how to use the 'dilithium crystal' pattern in my guestbook" ... I start to worry.

<ps>If there is not in fact a `dilithium crystal` pattern then there should be & its high time someone did something about it ~ </ps>
Until

[Selkirk]

I hadn't heard of Wireframes before. A little googling turned up a Good explaination on a cool wiki.

It reminds me a bit of the method that Larry Constantine outlines in Software for use. He advocates designing user interfaces with low fidelity prototypes. (Sticky Notes!) Sometimes less is more.

I notice that there is a book out on Paper Prototypes. I'm anxious to read it. Sadly, my reading list is getting a bit backed up.