Page 4 of 4

Posted: Wed Jul 25, 2007 2:59 pm
by Jenk
An object is supposed to encapsulate a single "behaviour." Having an object encapsulate more than one "behaviour" is a code smell. This is why you'll see classes for database accessing; the behaviour is "Accessing the Database" - note that accessing the database does not include handling data; purely accessing. It is then the responsibility of another object to handle that data, another object to read that data, another object to display the data, and so forth.

Posted: Fri Jul 27, 2007 10:36 am
by thinsoldier
so...say i'm doing something for a real estate site.
I have an object that gathers all info for a particular property and makes the data suitable for displaying to the public.

I should really have:

1. object that accesses the database
2. object that handles the returned data resource and turns it into an array
3. object that performs the various methods on different parts of data to format them for display
4. object that takes the data and the html template and puts them all together ready to be displayed

is all that really necessary?

Posted: Fri Jul 27, 2007 10:48 am
by superdezign
thinsoldier wrote:1. object that accesses the database
2. object that handles the returned data resource and turns it into an array
3. object that performs the various methods on different parts of data to format them for display
4. object that takes the data and the html template and puts them all together ready to be displayed

is all that really necessary?
Necessary? You've hardly scratched the surface. :P

Object-oriented programming isn't meant to be a necessarily quick and painless process. Most websites with a lot of functionality and dynamic content can end up with a monstrous amount of classes and objects, but everything has a purpose. The way you should see your classes is that it has a purpose, so it needs the abilities (functions) to perform it's duties, and the information (data and class members) to do it correctly. It's like a worker needing both the tools, the materials, and the skill to build.

When you build anything, you must think about maintenance. OOP is very manageable and organized.

Posted: Fri Jul 27, 2007 3:55 pm
by Ollie Saunders
superdezign has it spot on but not only that but you should write unit tests for each.

Posted: Thu Aug 16, 2007 4:09 pm
by thinsoldier
thinsoldier wrote:so...say i'm doing something for a real estate site.
I have an object that gathers all info for a particular property and makes the data suitable for displaying to the public.

I should really have:

1. object that accesses the database
2. object that handles the returned data resource and turns it into an array
3. object that performs the various methods on different parts of data to format them for display
4. object that takes the data and the html template and puts them all together ready to be displayed

is all that really necessary?

2. object that handles the returned data resource and turns it into an array
??huh? an object just to call mysql_fetch_assoc($result) ??

sometimes I think people take OOP into overkill territory

Posted: Thu Aug 16, 2007 4:47 pm
by AKA Panama Jack
thinsoldier wrote:2. object that handles the returned data resource and turns it into an array
??huh? an object just to call mysql_fetch_assoc($result) ??

sometimes I think people take OOP into overkill territory
You are right some people overuse objects thereby slowing down execution. Objects for PHP shouldn't be used for every single thing but for specific tasks. Most of the time pure procedural programming is all that is needed. Usually sticking something into a class ends up using more memory, CPU and other resources than it would if it was created as a procedural. And the argument that using object coding makes the code easier to understand is utter nonsense because I have seen spaghetti objects.

Posted: Thu Aug 16, 2007 6:08 pm
by superdezign
thinsoldier wrote:2. object that handles the returned data resource and turns it into an array
??huh? an object just to call mysql_fetch_assoc($result) ??
You wrote that list, not us. The object that would handle the MySQL results resource would be responsible for a lot more than just returning an array. Error handling, getting statistics on the data, saving the query for debugging purposes, ALL of the mysql_fetch_* functions (not just the associative array), etc.
thinsoldier wrote:sometimes I think people take OOP into overkill territory
Sometimes they do, but PHP isn't C++. C++ is where a lot of us learn OOP and C++ has a lot of different types of objects. PHP has classes and interfaces. It is limited, but capable. I think you are just looking at OOP from the wrong angle. An object is an OBJECT. Not a handler, not a helper, but an object. Objects represent something in the sense of a noun with responsibilities, abilities, and attributes. When you added that suggestion to your list, I assumed you were actually referring to an object that had returning the array as one of it's responsibilities. The fact that you even considered it just a way to call a function shows that you obviously have a flawed view on the way OOP works.

Posted: Thu Aug 16, 2007 7:38 pm
by Christopher
thinsoldier wrote:sometimes I think people take OOP into overkill territory
I have yet to see that in PHP. I have seen poor implementations that use both functions and classes inappropriately, but I have yet to see the overkill you claim "people" do actually done by competent PHP programmers.
AKA Panama Jack wrote:You are right some people overuse objects thereby slowing down execution. Objects for PHP shouldn't be used for every single thing but for specific tasks. Most of the time pure procedural programming is all that is needed. Usually sticking something into a class ends up using more memory, CPU and other resources than it would if it was created as a procedural. And the argument that using object coding makes the code easier to understand is utter nonsense because I have seen spaghetti objects.
Now, now PJ ... I know you are wise enough to know better than to make arguments like that.

- Your first sentence claims this unknown group of "some people" do this unspecific thing of "overuse objects" and that they "thereby slowing down execution." Even if the hypothetical people and overuse were identified, is the slow down 0.01% or 1 zillion percent?

- Then you make a statement about objects that also happens to be true of every other thing in a programming language -- they all should be used for everything, but only for specific tasks. It is true of the + operator as well as objects.

- Then you make an ambiguous statement that "sometimes" can use more resources. Obviously sometimes true! But you don't discuss that using resources is often a question when programming and that using more of a resource, such as memory or disk, may improve things like performance.

- And finally you imply that because you have seen some "spaghetti" classes that that makes all classes less readable than, I assume, procedural code. That's like saying that because sometime people wearing seat belts in car crashes die that seat belts shouldn't be used.

I know you goals are grouchily noble, but a little balance please -- especially because we tend to have a more balanced and less bigoted membership here than other forums regarding OO. We acknowledge the small memory and performance hit of objects in PHP, we strive to learn more to continuously improve our programming toolboxes (like saving objects in the session ;)), and at the same time acknowledging the design, testing and implementation benefits that are the reason that all modern programming languages are OOP.

Posted: Thu Aug 16, 2007 9:40 pm
by AKA Panama Jack
arborint wrote:- Your first sentence claims this unknown group of "some people" do this unspecific thing of "overuse objects" and that they "thereby slowing down execution." Even if the hypothetical people and overuse were identified, is the slow down 0.01% or 1 zillion percent?
Well, if you would do some testing you would know from first hand accounts that using Object code in PHP is very slow in CREATING the object. The larger the object being created the slower the creation. Also, the internal structure of the class will also impact upon object creation speed. In my testing a 100K class could take from 0.05-0.2 seconds to be created, depending upon the internal structure, where the same 100K code written as a non-class takes virtually no detectable time to be loaded. Now you multiply the object creation time by the number of page accesses per second you have a HUGE problem. Using smaller classes takes far less time to create. If you break down the 100k mega-class into 10 smaller classes the impact is slightly less but not as low as using no classes.

A good example is ADOdb and ADOdb Lite. There is a small difference in execution speed of the functions contained in each class. ADOdb Lite is slightly faster in executing the functions after the class has been created. That is because of optimized coding.

But the REAL speed increase comes from the object creation. ADOdb Lite is over 3 times faster at creating the object than ADOdb. Benchmark This is because the code is considerably SMALLER. This is where PHP Objects fall flat on their face. Object creation in PHP is gawd awful SLOW and gets slower the more code you add to the class. Also, certain methods of extending classes can be horribly slow.
arborint wrote:- Then you make a statement about objects that also happens to be true of every other thing in a programming language -- they all should be used for everything, but only for specific tasks. It is true of the + operator as well as objects.
Now that statement didn't make any sense when referencing what I mentioned before.
arborint wrote:- Then you make an ambiguous statement that "sometimes" can use more resources. Obviously sometimes true! But you don't discuss that using resources is often a question when programming and that using more of a resource, such as memory or disk, may improve things like performance.
Ok, I was wong. Classes ALWAYS use more resources. :D And with classes you are not really improving speed by using them because class creation is so slow in BOTH PHP 4 and PHP 5. I keep hoping they will improve it in PHP 6 but so far there is no idication this will happen. The one thing Classes are good for is creating ISOLATED code that will be used by many different things in the main program. The vast majority of web site code never needs code isolation except for specific things. If you check, you will find that a few of the CMS packages out there suffer from Object Bloat and users have complained about how slow things get when there is a moderate amount of activity.
arborint wrote:- And finally you imply that because you have seen some "spaghetti" classes that that makes all classes less readable than, I assume, procedural code. That's like saying that because sometime people wearing seat belts in car crashes die that seat belts shouldn't be used.
No, you misinterpreted again. I was saying that Class coding can be just as obscure, convoluted and down right horrid as any procedural code. Just because it is a Class doesn't mean it magically becomes more readable. When you get right down to it the only real difference between procedural code and class code is the class code is walled off from the rest of the code with the class statement.

Code: Select all

function test()
{
    return "stuff";
}

echo test();

Code: Select all

class mytest
{
    function test()
    {
        return "stuff";
    }
}

$object = mytest();
echo $object->test();
The two examples above do the same thing but the object class uses more memory, takes longer to create and uses more CPU. Classes should only be used for specific things and never everything in PHP.

Just say no to code bloat.

Posted: Thu Aug 16, 2007 10:46 pm
by Christopher
And again, I acknowledged the memory and performance hit you get when using classes in PHP. In turn, you give examples of 100k mega-classes and code snippets that are so tiny as to be meaningless. You state platitudes such as that any style of code can be messy and smaller PHP files run faster than huge files. But you ignore all the benefits of OOP.

Memory use and performance are two measures of an application -- there are many others. I think that memory use and performance are not the most important measures in most PHP applications. They are certainly not considerations that should be foremost in the mind of beginning PHP programmers -- good design is much more important. It is also my opinion that the performance of a PHP application can be improved much more easily than the design can.

Posted: Fri Aug 17, 2007 12:00 am
by AKA Panama Jack
Good design does not require the use of classes. That is a complete fallacy.

I give you examples and you discount them. And 100k class isn't really a megaclass anymore. And you are ignoring what I said about CLASS size. There isn't any real speed difference between a 10k and 100k NON-CLASS file executing but there IS a big difference between a 10k and 100k class being created. That is what I think you are either overlooking or not understanding.

I don't ignore the benefits of OOP but I understand the LIMITATIONS under PHP. OOP in PHP is great for doing specific things like database classes as long as you KNOW WHAT YOU ARE DOING. But using OPP for every single thing on a web site is a gross misuse of classes under PHP.

I guess if you are creating PHP code for a dedicated server that has all of the processing power and memory possible then sure us classes for everything as you will be compensating for the deficiencies in using all classes with hardware. Basically the same thing Microsoft has done with Windows.

If you are creating applications that will be used on dedicated servers with high page hits or shared hosts then you have to keep memory usage, CPU usage and SPEED as one of the major benchmarks in creating your software. If this isn't drilled into NEW programmers we end up with coding that relies on hardware to cover for poor coding practices.

And it is HARDER to improve performance after the fact. I have found that you end up having to throw out the slow code and start from scratch to gain any performance. So you either end up wasting all kinds of time recoding what should have been written well in the first place or you just ignore it and hope no one notices the performance problems.

Don't discount my examples because you do not understand them.

Posted: Fri Aug 17, 2007 2:51 am
by Christopher
I never said that good design required the use of classes. That's a fine strawman argument, it's just not an argument to anything I said.

I also looked at my own code on a number of projects and the biggest class I can find is 14k. Most are 1k-4k from my quick survey. I don't know where you get the metric of 100k classes being common, but that size class seems against current practice. Large class size is a code smell. FYI - I checked through the Zend Framework code and except for one giant, kitchen-sink 177k Date class, most everything is small, with a few 20k-40k classes.

I agree that programmers should be aware of the memory and performance issues of using OOP in PHP. And I think it is fine to program PHP purely in procedural or mix procedural and OOP. Clean, well designed code can be produced by a competent programmer using any mix. But you seem to deny the existence of the many PHP applications that use OOP for "every single thing" and meet their performance and memory targets. I don't think you can accuse what is probably the majority of professional PHP programmers of "gross misuse."

I did not say that fixing performance problems is easy; I said that fixing design was more difficult (and sometimes the source of the performance problems). You seem to find that code performance and memory usage are major issue in you work. I find them to be a non-issue in mine. The performance problems I see are mostly from database queries or connection to other servers -- not code.

In general I agree with your concerns about object performance and memory use in PHP. However as someone who uses PHP in a way that you describe as a "gross misuse" and who does not have the problems you warn mightily about, I have to wonder about why you are saying what you are saying. You don't "misuse" PHP yet warn of the problems of misuse; I do "misuse" PHP yet don't experience the problems you claim.

Posted: Fri Aug 17, 2007 3:00 am
by feyd
I believe the thread is drifting into metadiscussion now. We should either bring it back in focus or split off this line of discussion for elsewhere.