From: tedd on 20 Jan 2010 15:13 At 11:18 AM -0500 1/20/10, Paul M Foster wrote: >On Wed, Jan 20, 2010 at 10:11:18AM -0500, tedd wrote: > ><snip> > >> >> While I teach OOP, I don't write any OOP for clients. My charge is to >> do things quickly and OOP requires a considerable amount of analysis >> before creating a solution. In most cases, I don't have the time. >> Besides, I'm more of an agile programmer and that doesn't lend itself >> well to OOP, IMO. > >This is a fascinating viewpoint. It's almost a sideways condemnation of >OOP: "It takes too long to write OOP for customers". (I know that's not >how you meant it.) But I have to agree, with one proviso. I tend to >write mostly procedural for clients because of time constraints. But I >believe part of the reason I do this is because I haven't built generic >OO components ahead of time which lend themselves to being used on >client sites. If I had spent the considerable time to build OO >components which were usable in this context, I'd be happy to use them. >OTOH, MVC (OOP on steroids) is just beyond reasonable in most cases for >client sites. > >I will also echo that it takes a lot of time/work to correctly build OO >components, compared to straight functions or function libraries. > >Paul Paul : My view of the world is limited to what I do, but to me it's almost a philosophical issue -- what constitutes reusable code and what doesn't? I've looked over many OOP routines that provided no useful purpose to me because their application was so specific that I could not use it for the problem I was solving. Programmers put these things together to be totally self contained, but failed to see that their solution only fits their problem. As such, for me to use their code I would have to disassemble it and then reassemble it for my own use -- in many cases taking it back to procedural. OOP makes sense if you and your client can agree on a final solution before any code is written. My experience with clients is that first I usually have to educate them as to what a web page is and then work to solve their specific problem, which in many cases they can't even identify. They can only say what they want. It's not their fault that they don't know what their problem is for they haven't been trained in problem identification. In fact, I would prefer an ignorant client over one who thinks they know how to solve the problem. I often tell clients to just tell me what you want and I'll work out the solution. I remember a sign that hung in an old gas station when I was a kid, which read: Labor: $10.00 per hour $15.00 per hour, if you watch. $20.00 per hour, if you help. In any event, when dealing with clients who don't fully realize what their problems are NOR fully appreciate what their needs are, I don't have the time to work out every detail beforehand so that I can create an OOP solution before writing the code. I might also add that writing an OOP solution before identifying the problem is an effort that will need to be redone later. Not all solutions should be written in OOP. Also, just because you can write OOP does not mean that what you write is better than what the procedural counterpart would be. It just means that you used OOP to solve the problem. So, to get back to your statement that I don't have time to write in OOP for clients, you are correct -- I can't spend the time necessary to do it. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: 64 bit date in 32 bit php ?? Next: Iterating ASTs with SPL in PHP-5.3.1 |