Re: What is/is not considered to be good OO programming
From: Google Mike (googlemike_at_hotpop.com)
Date: 12/09/03
- Next message: James Campbell: "Re: unexpected T_IF error"
- Previous message: Rob Tweed: "Suppressing HTTP Headers"
- In reply to: Tony Marston: "Re: What is/is not considered to be good OO programming"
- Next in thread: Tony Marston: "Re: What is/is not considered to be good OO programming"
- Reply: Tony Marston: "Re: What is/is not considered to be good OO programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 9 Dec 2003 10:01:08 -0800
Oh what the hell. Here's my two cents...
I agree with Tony Marston, if I read him right after skimming this
thread. Brit programmers have common sense, unlike most of my American
compatriots I have to interact with in the workplace.
OOP is way overblown. If you use it right, it's great. If you use it
wrong, and many pseudo-senior devs I've seen use it unnecessarily, it
can do nothing but introduce unecessary complexity and even slow the
app down.
For that matter, the same argument can be made for using XSLT to
abstract your presentation layer. XSLT is overblown and introduces
nothing but delays, I find.
The same arguments going on here in PHP are being argued like mad on
the .NET platform too.
Take for example a simple web-based checkbook app for a series of
users. You login, see your checkbook, and can make entries to it.
Here's what a series of developers might think:
psuedo-senior dev 1: Let's make a User object, Checkbook object, Login
object, Logout object, and an Entry object! Let's do objects for
anything we can think of!
psuedo-senior dev 2: Let's make the business layer push out nothing
but XML, then use XSLT to style this output for the end user.
psuedo-senior dev 3: I think we should make the data layer emit
nothing but XML.
psuedo-senior dev 4: I think we should make everything in stored
procedures and make it receive and emit XML. The presentation code can
be written in PHP to read the XML and style it with XSLT.
No. Not me on any of this, even if it were something as complex as a
Near Earth Object Tracking System, and I've been programming since
1979 and am 36 years old. My title says "Senior Developer". My take on
objects, XML, and XSLT would be:
1. I'd use an associate array (better known as a hash table by us old
f*cks), not an object, for the checkbook entry record.
2. Thinking about code-reuse for future projects, I'd bundle my
frequently used functions in a web class, strings class, db class, and
a settings class. That way, when I call a function (er, "method") like
Redirect, I can understand where this method came from, and so can
others who read my code, because I would have it listed in my code as
$web->Redirect('page.php'). If Redirect breaks, you instantly know
it's in the "_web.php" page (if you saw my Requires statement).
3. If an object isn't necessary, I avoid it like the plague. Not by
inexperience, but by /experience/.
4. When I have to work in teams, we decide on a set of pages and a
very small set of objects that we're going to assign to each team
member, and then we iron these out individually for a bit with test
harnesses. Eventually, we start sharing and interacting with each
others stuff when these start to stabilize.
5. I like XML, but I dislike XSLT. XSLT is way, way too difficult of
an implementation of a superbly fantastic idea. I'll wait until
something better comes out to replace XSLT. For now, you'll see me
doing and <% {code} %> and <%= $var %> in my code, although I try as
much as possible to reduce interruptions in the HTML because of the
speed hit. That's why you see me doing most of my code in the top of
the page before the HTML tags.
6. I like XML, but I don't want to make every thing a particular OO
layer run through it, such as making the business layer receive XML
and emit XML. I mean, I'm always on tight project schedules. Many a
stakeholder (end user) on a project will be intolerant of excuses
like, "I'm having problems with the XML." They want me to get in
there, fix the code, and it works. Right now I use XML for storage and
retrieval from text files, or for sending stuff over sockets, or for
interacting with another vendor's stuff. But that's all I've seen a
need for it.
7. I love the encapsulation/abstraction of objects when it makes sense
to implement that. And if OOP is tied in with a GUI, such as a window
or widget, it's cool too, such as the ability to use someone else's
widgets and make my own, or the ability to instantiate a window and
then subclass it. But I always ask myself, is this overblown for this
kind of solution? I like the situation forcing me into using OOP,
rather than starting with it in the first place.
8. If I'm going to make a loadable C++ module for PHP, hell yeah, I'd
use objects to be consistent with how third-party or intrinsic APIs
work in anything from PHP to VB to Java to other languages. But for
business app use, I let the situation dictate the need for objects,
not me project that into the situation.
9. Some portal products that your business app might "snap-in" to
might dictate that you implement your stuff in XML/XSLT, so I think it
makes sense there, just as long as someone proves to me that the
solution is fast enough and scalable enough.
- Next message: James Campbell: "Re: unexpected T_IF error"
- Previous message: Rob Tweed: "Suppressing HTTP Headers"
- In reply to: Tony Marston: "Re: What is/is not considered to be good OO programming"
- Next in thread: Tony Marston: "Re: What is/is not considered to be good OO programming"
- Reply: Tony Marston: "Re: What is/is not considered to be good OO programming"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
