Re: OOP slow -- am I an idiot?

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

 



Ed Lazor wrote:
On Oct 12, 2006, at 4:36 PM, Stut wrote:
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.

Indeed, that would be a very bad thing, unless you've already considered that. I've previously mentioned that I have an ActiveRecord-style implementation for a lot of my DB access. The base class for that system has a static function called FindAll which will return an array of objects. However, it only does a single SQL statement. The base class also has a method LoadFromArray which, shockingly, loads the object from an array. This means that from a single DB request I can get an array of objects each representing one entitity (potentially a row, but not necessarily).

Bear in mind that this is not always the best solution (as ever). Continuing the example from my previous email, I very much doubt that the UserCollection class would contain any instances of the User class. However, if you read back I did say that I would probably expose the methods in the User class to massage the data, meaning that any part of the data in the database that needs transforming before it can be used is handled by one piece of code whether it's for single or multiple records.

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?

It's rare for me to use any formal system for defining my object model, but when I do it's usually UML. If I remember correctly from my degree, CORBA is a remoting specification so I'm not sure how it applies here.

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.

"Situational" - that's a term I've never heard in this context before. To me what you're describing is evil. I use OOP to wrap data such that I can access it in a consistent manner from anywhere. The only SQL I ever write is in classes. While it's true that I could do everything I do with OOP functionally, using OOP forces me to think about how data and operations on data are connected.

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.

For me it's not a case of taking more time in development. Due to the nature of PHP, the way a particular class is used, its context, is more important to me than making it generic. I'll advocate code reuse until I'm blue in the face, but when performance is one of the main goals there is often little choice but to rewrite code to fit a particular situation. This is one of the reasons I steer clear of libraries like PEAR for anything but trivial sites - I can't guarantee that third party code will not adversely affect the overall performance of the site. In addition I've found that 9 times out of 10 it's quicker in the long run to just implement it myself - at least then I know exactly what it's doing and how, which makes it easier to fix and optimise later.

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?

If by providers you mean hosts then you're right. I actually run a hosting company and can only offer PHP5 because we recently went through a process of upgrading all our servers (painful that was!!) and a customer survey showed that over 90% of them wanted the upgrade - 13% said they were likely to switch provider within 6 months if we did not upgrade.

However, I do know that making such a move can be incredibly expensive, not only in obvious engineer time required to simply do the upgrade but the resulting support costs will be an order of magnitude greater even if the upgrades themselves go very smoothly.

I'm in a very fortunate position in that nearly all of my clients fall into one of two camps... those that are competent developers, and those with simple static sites.

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.

I don't use any third party code unless it's something I cannot implement or don't have the time to implement - both of which are thankfully quite rare. PHP frameworks are great if you want rapid development and your system fits nicely into the common structure, but they suck arse if you want to do anything even slightly different.

I actually use two different code structures - one at my day job which I can't say too much about (except that it's a mess by way of much incremental development), and the one I use for most of my personal/business sites. I'm currently writing an article describing the latter - I'll post a link to this list when it's finished if people are really interested.

-Stut

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