Ed Lazor wrote:
On Oct 12, 2006, at 12:15 PM, Stut wrote:
As such you cannot start designing a solution unless you know how the
data/entities are going to be used.
Doesn't this mean that your design breaks when the behavior or use of
the data/entities changes?
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.
OOP in PHP cannot start with basic building blocks, at least not if
you want a system that performs reasonably well.
Right. That makes sense with PHP being an interpreted language. I've
tried to offset this somewhat by compiling libraries and having them
cached before pages that rely on these libraries load.
I'm trying to get a better idea of how you leverage the advantage of OOP
in PHP. Do you use it? If so, how? Do you use any OOP methodologies?
If so, which ones? For that matter, how many of your projects start with
a detailed description of all data/entities and how they are going to be
used?
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.
For most projects I don't start out with OOP in mind, but my brain is
used to building OOP-style systems so nearly everything I do ends up
with a few classes.
For example, I'm currently working on a site for a couple of friends of
mine. The site has an extremely simple user system - hard-coded
passwords (evil I know, but it's what they asked for). When I first came
to authenticate the user I naturally created a User class with three
static methods: Login, Logout and IsLoggedIn. The class stores the
logged in status and access level in the session. When I actually get to
implementing something that requires a logged in user I will create
another static method called Can which will tell me if a user can do a
particular thing.
Off the top of my head, that Can method will look something like...
static public function Can($action)
{
if (!self::IsLoggedIn())
return false;
return (in_array($action, $_SESSION['user']['perms']));
}
For this simple example everything is hard-coded and all data required
is stored in that class, including the passwords and actions allowed by
each access level.
Now consider that a couple of months down the line they decide they want
to implement a complete DB-based user system, all I do is modify the
User class to add the methods that would need incorporating getting
users from the database. I can do this because I know that each visitor
will only be accessing one user at a time so the performance hit is
negligible.
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.
Does your experience differ a lot from mine? My customers rarely have a
complete understanding of what they'll be doing. They usually only have
a general idea. Part of my challenge is to help them define that idea,
especially when it comes to defining the scope of the initial project.
Yes, scope creep is to be avoided or managed in projects, but customers
are always finding new and creative ways to apply their ideas. Things
have to be flexible enough to support current needs and future needs.
You're saying that you cannot start designing a solution unless you know
how the data/entities are going to be used. I'm saying that you have to
start somewhere and that code has to be extensible enough to meet
growing demands. I'm sure that you try to come up with flexible
designs, but I'm wondering. What is your approach?
To me it's all about numbers. I think the worst way you can apply OOP in
PHP is by-the-book. What you need to do is look at defining your
entities in relation to their existance within each request. Taking my
user example above, I know that for the bulk of the system only one user
will ever be needed. This makes it perfect for an object-per-record
implementation since there is only one record.
When I discuss a system with a customer my head is taking what they are
saying and mapping it into several entities, not all of which will
become actual classes, but all of which help me organise the site before
doing any coding. Examples of these entites would be sections of the
site, individual pages, data sets, access limits, etc. and the way those
will interact with each other to provide a solution.
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.
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.
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.
I'd also like to say that OOP itself is not hype. In the same way that
podcasts themselves are not hype. It's what surrounds stuff that gives
it the uneasy feeling that it's hype. Podcasting is the next stage of
audio and video entertainment in the same way that colour TV was all
those years ago. They hype exists because of the cruddy media-driven
world we now live in where everything has to be hyped up if it's going
to be popular, even if it's short-lived.
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).
OOP is good, but it needs to be used where appropriate to the context.
OOP should not be used for the sake of it, but it should also not be
dismissed as a fad or hype.
On Oct 12, 2006, at 2:29 PM, Richard Lynch wrote:
Rapid prototyping in OOP, if you're willing to chuck the prototyping
if it turns out to be the "wrong" OOP model is do-able.
Do you end up throwing away a lot of code?
I can't speak for Richard, but hell yeah! I've probably thrown away more
code than the amount I've written that is still in use. This is a
fundamental hurdle that all developers need to get over. Not so
prevalent now with the fresh developers arriving in the job market now,
but in previous years there were too many who would refuse to throw away
any code they had written for what I can only guess are sentimental reasons.
Write it once. Realise that it's ugly and wrong. Write it again. Realise
that it's right but could be improved. Write it a third time and you
should have a work of art.
If you're not willing to say "that code I just wrote sucks", IMHO you're
not a very good developer. In addition, if you're not willing to throw
said code away because it "too me hours", IMHO you're not a very good
developer.
BTW, this is not related to OOP in the slightest. The same would go for
any methodology.
Even building the basic blocks first is fine -- but you've got to have
the whole structure in your mind if you expect those blocks to fit in
well.
It sounds like you (Both Stut and Richard) have done a lot of this, so
I'm sure you know what you're talking about. Like I mentioned in my
original post, I think I need to spend time learning better object
modeling in order to take better advantage of OOP. I still can't help
but wonder. How do you know if you have the full structure? Don't you
end up going back and changing things a lot?
Yes you do. And you should. If you don't then you've almost certainly
done something wrong, probably not tested it enough.
This is probably not really specific to OOP, but I think it tends to
be more obvious with OOP when you start trying to "work around" the
short-sighted architecture. By which I only mean that in procedural
programming, the work-arounds feel less like work-arounds, at least at
first, as they are not so obviously work-arounds, and just look like
more functions.
I'm honestly not sure if I understand what you're saying here, but I do
know that I've always tended more toward linear / procedural programming
with a lot of functions. I have used OOP, but in very limited capacity
- mainly to avoid the system overhead. I think I've also avoided it
because I usually run into problems with defining data in objects -
similar to the original issue of creating a customer object only to run
into the problem of how to handle objects that represent a collection of
customers. Again, me needing to get a better understanding of data
modeling in OOP. It seems like you still end up having to learn data
modeling "the PHP way"; people are probably critical of PHP because of
this, but it seems like there's a middle ground and I'm curious where
you guys have found that to be. Should I take this off the mailing list
and talk with you about it in separate email?
OOP-based data modelling in PHP cannot be approached in the traditional
OOP way for the reasons already mentioned.
To get back to the ORIGINAL point -- OOP is not about raw performance.
It's about maintainability, code re-use, encapsulation, etc.
You can get acceptable performance from OOP if you know what you are
doing -- If you don't, it's super easy for a beginner to write a total
performance hog following all the best practices in the world.
Definitely agree with you there.
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 classes in PHP5 significantly slower than a functional solution?
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
