Re: Objects, objects, so many objects! ;-)
From: Bruce Wood (brucewood_at_canada.com)
Date: 12/13/04
- Next message: Scott McNair: ""Error Creating Control""
- Previous message: John: "RE: ASP.Net unable to start"
- In reply to: thechaosengine: "Objects, objects, so many objects! ;-)"
- Next in thread: Bob Grommes: "Re: Objects, objects, so many objects! ;-)"
- Messages sorted by: [ date ] [ thread ]
Date: 13 Dec 2004 14:42:16 -0800
None of us really _needs_ objects. As you pointed out, we could write
everything using static methods and static properties. That's what I
used to do 10 years ago. It was called structured programming, and I
used C.
I'm not being sarcastic: people programmed in non-OO languages for
decades. The modern equivalent, in an OO language, is to make
everything static.
What your question boils down to, essentially, is: what are the
advantages of object oriented programming over structured programming,
and when should you apply object technology versus structured
technology?
The difficulties with using structured programming as you described in
your example are as follows.
o WIthout an object to stand guard over your user's phone number, how
can you be sure that the phone number is being set only by the static
method and isn't being diddled by your caller? If you're using a
"private" static string to store the phone number, and only allowing
access through a public static method, then in essence you've created a
singleton and only allow there to be one user in memory at a time. If
you want multiple users in memory at once, then somebody, somewhere,
has to remember their phone numbers. Without objects you rely on the
application program to promise not to muck with the phone numbers
except by calling your methods, because without objects you can't
encapsulate state.
o Without an object you can't easily encapsulate business rules. What
if whenever a user's phone number is changed you have to also make
calls to update the Address Book in Exchange? Does the application have
to remember to do this? Objects make this sort of thing much easier:
the application can just say user.PhoneNumber = "..."; and the object
verifies the new number and looks after informing Address Book that it
has changed.
However, objects aren't good for everything. I remarked elsewhere that
some of the worst designs I've seen were the result of newbie
programmers trying to make everything an object. Objects are really
good for low-level stuff that you can put a name to, like "user" or
"purchase order". Once you get up to a sufficiently high level, like
the top level of an application, the usefulness of calling such big,
complex things "objects" starts to fade rapidly.
- Next message: Scott McNair: ""Error Creating Control""
- Previous message: John: "RE: ASP.Net unable to start"
- In reply to: thechaosengine: "Objects, objects, so many objects! ;-)"
- Next in thread: Bob Grommes: "Re: Objects, objects, so many objects! ;-)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
