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
