Re: OOP slow -- am I an idiot?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Oct 12, 2006, at 4:36 PM, Stut wrote:

You may end up refactoring code if your application changes that much, but a good OO design should also mean that when changes of that magnitude occur the changes required are limited to relatively small sections of code.

Ok, I think we're using the same approach here. I also noted the earlier comments about BUDF and I'm exploring those. It would be nice if anyone else has more examples of standard methodologies applied to PHP.

My general approach to designing a system is data-centric. I tend to start by defining the database schema since getting that clear in my head tends to lead me to a decent design.

Same here, most of the time. There are a few situations where I focus more on just giving the customer canned solutions and finding ways to integrate them as easily as possible. This is usually when the customer wants all kinds of features, but they can't really afford them. For example, one guy approached me the other day asking me to code forums, a community calendar, news, a "rant" section, a products database with inventory management, a shopping cart system, and coming up with a layout and design that integrates it all... then he said... he needs it in two weeks, it has to be priced under $400, and he needs to be able to easily update content on his own. ugh. I told him flat out that his price was way off and that he'd best go with pre-made solutions like PHPBB to get what he's after.

If I then go on to create an admin interface for the users, I would create another completely separate class called UserCollection to handle more than one user. I may at that point choose to expose any data-massaging methods in User to UserCollection to avoid code duplication, but that would be the extent of the way UserCollection uses the User class since the User class is optimised to work on a single user at any one time.

We use a similar approach for the user class. I haven't ever implemented something like the UserCollection class though. I'm curious about that. Does your UserCollection class extend the basic user class? Or is it something else entirely; I dunno, maybe UserCollection has a property defined as an array of User class? I think that's what people were saying earlier in the thread as being a "very bad thing" in terms of memory utilization, etc.

How to properly define the User class and UserCollection classes also seems to delve into issues of UML and CORBA, which I don't have a lot of experience with. Is anyone applying those technologies to PHP?

This makes it perfect for an object-per-record implementation since there is only one record.

Yea, but I keep thinking back to how the implementation of data representation is separate from the implementation of how that data is used. Going back to the users example, I created a User class. I never bothered to create a UserCollection class because coding that does anything with a collection of users typically ends up being situational. Say I want a list of customers. I could create a UserCollection class with a method called list... and I could have it query the db and dump general fields. That seems like a fairly generic approach, so it might work, but I usually want to do something with individual fields - like link to a specific webpage to view more information on the customer, edit the customer record, delete, etc.. I know I could code all of these features into the class... but it reaches the point where it seems like overkill. It seems better to just create a webpage that has code to handle that.... which is what I end up doing. Mind you, I once created a bunch of classes that did all of the cool "pretty" formatting, table layout, with customizable doohikies, but that's where the classes started getting bloated, the system started bogging down, and there were very small, but very noticeable, delays in loading pages. I guess that leads me back to wondering how you implemented the UserCollection class or, at least, what features you built into it in order for it to be of benefit. I'm also assuming (uhoh hehe) that the same thing applies to other object hierarchies - for example, one class that defines a product and another class that defines a collection of products.... wondering how the two would be implemented to maintain efficiency... and I'm guessing your answer is that how you implement it depends on the situation... whether the site focuses on using individual products the most or ends up working with collections of products most... but it seems like it wouldn't matter... ie. again, the separation of data from implementation.

All requirements change - fact of life. Customers never know what they really want. OOP will not shield you from the effects of having the system specification pulled from under your feet. However, it can be used to lessen the blow by anticipating what those future changes might be. That comes with experience and no methodology can get completely around it.

True, very very true hehe

Also, isn't OOP supposed to be about separating data from programming logic? If that's the case, isn't how you use that data irrelevant? That seems like one of the greatest promises of OOP, but maybe that's just the hype?

Yes and no. OOP actually brings data and the logic that works on it together, while keeping logic that doesn't work directly on the data awway. One of the core aims of the OOP methodology is to hide as much of the data behind an API that allows the implementation of that API to change without affecting how that API is used.

Ok... I'm with you so far...

Having said that, it doesn't apply too much where PHP is concerned unless you are developing a set of classes for public consumption. What is more important is that by packaging data and logic together you end up with one place where it all happens, and you can choose how much of the internal workings are exposed to the rest of the system.

The only difference here is that I'd probably aim for all classes to be good enough for public consumption, but I know that takes more time in development.

Podcasting is the next stage of audio and video entertainment in the same way that colour TV was all those years ago.

*cough* AskNinja.com RULES! hehe *cough*

To relate that twoddle to PHP... OOP is a stable, mature methodology. However, OOP in PHP is fairly new (if you ignore PHP4's pitiful efforts) and there's still a lot of unease about this new kid on the block, along with a lot of hype around the idea that it will launch PHP into being a "real" programming language instead of just a "web-based toy" (can't recall where I read that, otherwise I'd provide a reference).

Yea, that's why I was making sure to get PHP5. It seems like providers are still lagging in implementing it tho?

I'd quite like an opinion from a Zend Engine developer here. As I've previously mentioned I primarily work with a fairly large OOP- based system but haven't noticed any great performance drain. While it's true that we use Zend Platform on both our development and production servers that's purely due to the sheer number of files involved in each request - something that would still be a problem if it were 100% procedural. And even without the platform enabled it's not particularly sluggish.

Are you at liberty to talk more about the OOP-based system you use? It is a PHP developer sweet or something? I've seen a few, but I've never used them.

Are classes in PHP5 significantly slower than a functional solution?

I'm trying to find it, but I saw a test of this awhile back pointing out that classes introduce a lot of overhead... having to load a function into memory versus loading the class and then instantiating it, etc. before you can call anything...

I'm really curious if any other developers have feedback or comments on this, especially the OOP methodologies.

-Ed

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux