|
|
Posted by Jerry Stuckle on 08/26/05 01:39
Kenneth Downs wrote:
> Jerry Stuckle wrote:
>
>
>>The real beauty of properly written OO is to separate the data
>>representation
>>(i.e. storage, etc.) from the use of that data. A simple case - I needed
>>to get a web site up quickly (one day) on a (low cost) host where MySQL
>>wasn't working
>>reliably. While the host worked on the problem, I created classes
>>representing
>>the data storage which used CSV files and stored all my data there. I
>>created
>>all the dynamic web pages based on the classes. Once they got MySQL
>>working
>>properly, I simply changed the classes to use MySQL instead. I changed
>>only the
>>class files - instead of numerous web page files.
>
>
> What you did is easily done w/o resorting to OO. It's even easier when you
> are not messing with OO because you don't get the confusion of having
> methods with the same name in multiple places doing differen things.
>
> A good programmer will always have a wrapper layer between his own code and
> outside systems like databases. There is always some program "Query()"
> that can be quickly rerouted to pull CSV's instead of tables, or Oracle
> instead of Postgres.
>
> You have good habits, but do not mistake them as features of OO, because
> they are not. Anything possible in OO can be done without it, usually with
> less code and usually it turns out to be easier to maintain.
>
>
Kenneth,
As I said - this is basically "object based programming" - without the advantage
of objects.
Actually, one of the greatest advantages to OO programming is the ability to
have functions WHICH DO THE SAME THING have the same name. I never have
functions with the same name do different things!
For instance - in my DB objects, I have fetch(), add(), delete() and update()
functions. In every db object they do the same thing. That way I don't need to
remember that it's fetch() in one object and get() in another one.
And no, I find non-OO code to be much HARDER to maintain. It doesn't take mode
code when both are done properly. And you need to remember all kinds of
different function names - even though the do the same thing.
Also, you have to worry a lot more about the side effects of changes you make.
Structure members are not private, for instance. No, YOU didn't code to access
the members directly - but who's to say someone else didn't? Encapsulation
prevents that from happening.
I've written a lot of non-OO code in my time - I started in 1967, well before OO
came out. I've only been doing OO since 1988 or so - mostly C++ and Java before
PHP.
As to "Anything possible in OO can be done without it". How do you do
inheritance and polymorphism in non-OO code? I'd love to see an example of
that. And as above - how do you ensure encapsulation?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|