Page 1 of 1
Classes vs. free standing code vs. functions
Posted: Tue Sep 21, 2004 1:58 am
by Steveo31
I am curious to see what you guys think about what tasks require what type of coding. For instance, new members signing up... I was thinkin classes. However, I've done fine in the past with functions. Are classes every really needed? Or are they just a nice element to have to have a more organized document?
Please share

Posted: Tue Sep 21, 2004 2:53 am
by Roja
Here's my take on things.
When you start.. lets say, doing a hello world program, you probably just need some freestanding code:
Of course, in time, that program will grow - soon you will have some nice features, like adding the users name.. suddenly you need a function..
Code: Select all
echo "Hello " . get_username() . ", welcome to our world";
But eventually, you have an entire profile for the user.. in which case, classes and objects can be nice..
Code: Select all
echo "Hello " . $user->formatted_name() . ", welcome to our world";
echo "<br>Your timezone is " . $user->timezone;
So, to me, its about complexity and design. If its going to be complex, or you want a tighter containment of variables, then classes/objects are ideal. If you want basic functionality, functions do the job well (pun intended). And every now and then, you just need a little standalone code to get something done.

reusable
Posted: Tue Sep 21, 2004 3:00 am
by phpScott
My feeling is that classes are all about being able to reuse and share your code easily. So for your example a new user would make a great class as you will probably being getting the same user data on any site that you build that requires a registration process.
EX: name, email, username, password and maybe optionally address, phone, etc...
functions are for things that you might need to process that don't fit nicely into a class.
If you program in things like Java then everything is a class and you have memeber functions every. Of course that is just standard in OOP.
More and more the programming world is moving to OOP development just look at the migration in php from 4 to 5 a big shift to classes and OOP.
Thats my two cents.
phpScott
Posted: Tue Sep 21, 2004 3:52 am
by CoderGoblin
There are probably as many views on this as there are programmers
My personal opinion is classes and objects should be used where modifications to something have knock on effects, or modifications can only be performed with restrictions. Common examples in books is a car. Cannot set speed unless you switch it on. Cannot switch car off unless speed is 0 etc. Without this distinction, especially if you are using a database, all you are creating is a list of functions to a list of variables. Just think about the OO names "Object" which has "methods".
Posted: Tue Sep 21, 2004 3:59 am
by patrikG
Posted: Tue Sep 21, 2004 6:11 am
by McGruff
Classes don't do anything you can't do (much more messily) in procedural code: a computer will happily work with any old spaghetti as long as it does actually parse.
The problem is that people can't. This is what it's all about: writing code that's easy to read and work with. With OOP, you're speaking to the programmer more than the computer.
Encapsulation makes code more modular, isolating discrete responsibilities and roles in separate code components. The application becomes much easier to read and maintain, as does any complex system once it's broken down into smaller parts.
A forum app, for example, is definitely a candidate for OOP. Different people might jump ship at different stages on the way down to "hello world" but I think I'd be one of the last to go. For starters, I couldn't live without unit testing (see link below).
I'd say any script more than 100 lines or so will probably benefit from refactoring into some classes.
OOP and testing are essential if you are serious about learning to program well. In php, you don't have to, of course.
Posted: Tue Sep 21, 2004 1:49 pm
by Christopher
I think the thing that gets overlooked about implementing OO in PHP is that though PHP is an improving OO language, it is a terrible OO envoirnment. The reason: non-compiled languages become very inefficient when you do deep inheritance and composition. Look at the depth of J2EE and .NET object heirarchies. Look at the number of includes in the average Java program. Includes of includes of includes can be a real performance killer in PHP.
I think PHP programs work best when they are Procedural at the top level, OO for the reusable middle layer, and Procedural at the lowest level (and no POOP sandwich jokes please). This works best because a PHP program rus an an unlinked group of files in which only a few of the files are executed during each request/response cycle.
Posted: Tue Sep 21, 2004 1:51 pm
by feyd
POOP,

I love it..

Posted: Tue Sep 21, 2004 2:19 pm
by McGruff
Once more into the breach...
A post by Lastcraft (see the first link Pat posted above) is the best response I've seen to the accusation that OOP is inefficient. As he points out, alleged losses are often more imagined than real, and do not address the real problem of good program design: how easy is it for people to work with the program? Concerns about "performance" are looking in the wrong direction ie at the machine end of the code interface. Within reason, modern computers are pretty quick no matter what you throw at them.
Posted: Tue Sep 21, 2004 3:49 pm
by Christopher
If there's a breach I'll jump too...
I have a problem with the idea that OOP is somehow related to good program design. That sounds more like hype by the OOP crowd.
There are studies, but no one has proved that a good programmer implementing a good program design is any more efficient than writing Structured or OO code. Or that the code is any more supportable, or error free, etc. You may like the ideas better, but that is beside the point.
I don't think anyone is proposing an explosion of Smalltalk for web development. Sounds crazy, but that is the language the OOers still reference in their patterns and theories. I love OO, but it has a major impractical streak.
Java is finally getting a foreach loop because Structured programming works. They finally realized how dumb Iterators are in many cases (and we just got SPL). Smoothly mixing structured and OO is one of the things that make PHP great.
Plus, you can write Structured code using classes and use OO design for a Structured coded system. Religions like OOP are good when the benefit programmerkind, but bad when the limit thought.
The PHP Way is not the Java Way.
Posted: Tue Sep 21, 2004 4:18 pm
by Steveo31
Great info here, thanks guys.
POOP...

Posted: Tue Sep 21, 2004 4:32 pm
by Roja
McGruff wrote:
The problem is that people can't. This is what it's all about: writing code that's easy to read and work with. With OOP, you're speaking to the programmer more than the computer.
This is *definitely* a matter of personal opinion. I've seen thousands of lines of code - both procedural, and classes.
I find the procedural to be much easier to understand at a glance. Worse, the "best" OOP code, when using iterators, and other abstract concepts are just plain ABSTRACT!
Most of my projects, (because I've inherited so much legacy code), are roughly 80% procedural, 20% class. If I had my way, it would be much closer to 60%, 40%.. it gets closer each day, but I only have two hands.
Point being, I definitely don't agree that classes - are by their nature - "easier to read and work with". In fact, I'd say just the opposite - procedural code is obvious, OOP is usually abstract.
That said, the reason I love classes is their easy extendability - extending a class is a core benefit of them.. they were DESIGNED to be extended. The same cant be said of functions.. functions are mostly designed for (at best) stacking.
So, there is an advantage to classes and OOP, I just dont agree that its more readable.
Posted: Tue Sep 21, 2004 5:39 pm
by McGruff
Hiding implementation behind an interface certainly makes code more readable for me: I don't need to waste my time reading through the details to figure out what's going on.
In fact, sometimes you don't even need to know the details while you're coding. More than once I've been refactoring a class (backed up by test cases) and just took a wild guess at what to do to get rid of the red bar - and it worked. You couldn't get away with that if you weren't working with OOP and a unit-testing framework. Instead, you'd have to take the time to read it carefully, figure it all out and (lacking tests) you still wouldn't be 100% sure if it was bug-free.
If you are sceptical about iterators you probably won't want to look at this:
http://cgi.mcgruff.plus.com/php/search_engine/.
As well as the benefit of hiding collection-types, iterators can avoid having to make copy arrays or repeated loops over the same array. They are in fact extremely efficient tools. And, in the search SQL example, iterators (and decorators) provide the clearest & simplest way I can think of to express the problem.
One piece of procedural code I can't avoid writing:
But that's about as far as it goes

Posted: Tue Sep 21, 2004 6:54 pm
by Weirdan
Roja wrote:
Point being, I definitely don't agree that classes - are by their nature - "easier to read and work with". In fact, I'd say just the opposite - procedural code is obvious, OOP is usually abstract.
as any abstraction, OOP is designed for people, not for computers. Abstractions help us understand and manipulate complex concepts in mind. It's just like raising numbers to the n-th power. While n is little you can think of it as number*number*....*number n times, but it's easier to think of it as an exponent when n becomes greater.
McGruff wrote:
Hiding implementation behind an interface certainly makes code more readable for me: I don't need to waste my time reading through the details to figure out what's going on.
Functions are for that very purpose as well, you're hiding implementation details (function body) behind function signature. The only thing classes provide is hidden argument ($this) to each method (which makes life easier). And so OOP is just one more step further to abstraction, it's not really a replacement for Structured programming.
It's up to the programmer to decide whether this step beneficial for certain task or no.
Posted: Tue Sep 21, 2004 7:37 pm
by Christopher
Hiding implementation behind an interface certainly makes code more readable for me: I don't need to waste my time reading through the details to figure out what's going on.
I agree that most of the time hiding the implementation behind an interface is a good idea. But you can build interfaces in both procedural and OO styles. A class is no more or less of an interface than a procedural library. And neither guarantee a good interface which is much more important.
Also, I'm not skeptical about iterators. I use them all the time. But in PHP a foreach over an array is a clearer, faster, simpler solution in many cases.