Re: OOP slow -- am I an idiot?

"Stut" <stuttle@gmail.com> wrote in message news:452ED193.8080707@gmail.com... > 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. What a coincidence! That's exactly my approach, but I've taken it one step further. I always start with a properly normalised database which I can then import into my daa dictionary application. From there I can press a button and create a class file for each database table, and I am ptting the finishing touhes to a procedure whereby I can press another button to generate the scripts which will maintain each table. This means I can get basic transactions up and running without writing a single line of code. All I have to do is edit these files to include business logic and any customisations. This level of automation is not possible with some people's OO implementations, so I can only conclude that their approach is not the optimal one. > 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. The difference with me is that I don't waste my time with trivial websites, I concentrate on administrative web applications. But even when I wrote the code for my own website at http://www.radicore.org I still used all my database classes as it was far easier than doing it the traditional old-fashioned way. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > 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