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
