Comments / Questions below. On Oct 12, 2006, at 12:15 PM, Stut wrote:
Except that is the attitude that leads to painful OOP in PHP. PHP is not the same environment as C++. The environment (classes, objects, etc) needs to be created and destroyed with each request.
I definitely agree that PHP is not the same as C++. I agree with the need for high efficiency and performance with low overhead. Actually, it's funny you mention that, because I've argued those same points with C/C++ coders new to PHP.
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?
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?
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?
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?
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?
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?
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?
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. -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
