Objects, objects, so many objects! ;-)

  • Thread starter Thread starter thechaosengine
  • Start date Start date
T

thechaosengine

Hi all,

I have a very general but quite significant question about objects.

My question is, when should I create them? I know thats a crap question so
let me explain a bit further.

Lets take an example of user management against a database. Things I might
like to do include:

- Creating a new user
- Changing a users phone number
- Deleting a user
- Getting a users age
- Updating a users password

The thing with all this is not one of those operations require the
instantiation of a User object. You could do it through static methods.

The thing is, you the sort of operations above must make up 80% or so of all
operations on users. Likewise, operations similar to these ones effect most
business entities, be it a Bug or a Role or a Car object.

So my question is - is it really the case, that a good proportion of the
time, you dont need to instantiate an object at all to achieve your aims, or
am I using a poor approach to design my applications?

Many thanks to anyone who can share some advice.

Kindest Regards

tce
 
Hi tce,

While creating a new User would be performed via a static method, you would
still be instantiating a new User object as the return value of that method.
Here I make the assumption that you could have multiple users, making an
instance necessary. Another operation that would require a new User object
could be Update. For example, when persisting changes, it is quite
reasonable to retrieve the changed values, which could possibly not be held
in the original object.

Joe
 
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.
 
tce,

I use static methods and members fairly infrequently -- and most of those
are general purpose helper or utility functions that require no instance
data other than whatever is passed in via arguments.

It may help to think of it this way: a class represents a a real-world thing
or concept (or an abstraction of one) including its data (fields /
properties) and behaviors (methods). It's just a way to organize data and
operations on that data into a coherent package. In general, most "things"
a program deals with have data that varies from one "instance" to another.
You will create objects from these classes. If you have methods that are
appropriate for more than one class then you may have organized the code
incorrectly -- or you may actually have a general purpose utility function
that can be a static method of a utility class that may never be
instantiated.

If you have some data that would be the same for *any* instance of a class,
then make it a static field of that class. If you have some action that
would be the same for *any* instance of a class, make it a static method of
that class. Otherwise, yes, create objects, and don't worry about having a
lot of them -- quantity is not so much the issue as coherent organization.
Remember that the object code associated with an object is only loaded once
no matter how many instances you have. Only the instance data requires
per-instance memory storage. Most objects don't have that much instance
data, so you really aren't going to eat up all your RAM in a hurry.
Assuming you use basic common sense in your designs up front, worry about
having too many object instances only if it becomes a real-world resource or
performance issue.

--Bob
 
Hello TCE,

I just want to add one thing to the discussion.

It is simple to imagine objects to be the computerized version of a "thing"
with methods being the "verbs" and properties being the "noun attributes,"
and some objects work OK that way. However, this view is limited and
flawed. It will quickly lead to a dead-end where the value of OO
programming is unclear, while the cost is very visible.

I would suggest that you pick up a slim book by Alan Shalloway and James
Trott called "Design Patterns Explained"
http://www.amazon.com/exec/obidos/tg/detail/-/0321247140

This is an easy read.
Once you are done, you will have a MUCH better idea of how to use OO
methods, when to create an object, and what objects are really good for.

And... you will know when, and how, to create them.

--- Nick
 
Hi everyone,

Thanks for you're advice.

Well, everyone seems quite entrenched in the idea that making objects to do
stuff is good. Which is as I expected.

I still don't see WHY I would make an object to do stuff when there is no
real need. Someone mentioned that it's to hold business rules - but static
methods can hold these rules just as easily as an instance.

I'm not at all worried about the performance cost of making objects, its
just in a great many situations (and in a great many sample applications)
there doesnt seem to be much call for making an object to perfrom an action.

In the applications that I'm playing with at the moment, the only time I
actually create individual objects is when dealing with collections of
entities - where making an in memory representation has real benefits. For
other things, like making an update to a database, there just doesnt seem
much point. Bearing in mind that I'm making web applications here - a lot of
the time I don't want in memory collections of lots of objects - I just
don't seem to need them.

Thanks for your comments so far

Kindest Regards

tce
 
read the book that I recommended... you will go from asking the question to
answering it fairly quickly.

This is a leap of faith to get here, but once you see the value of OO
design, you will wonder how you ever lived without it.

--- Nick
 
The value of object oriented programming is not immediately evident
while you're writing the code. If it were, the industry would have
invented it in the 70's, not the 80's. You see the value only later,
when you try to modify your software in reponse to changing
requirements.

After all is said and done, objects are little more than a way to
organize your code so that things that belong together stay together,
and so that you can make hard-and-fast statements about what you can
safely change during maintenance and what you can't, and by "what you
can't" I mean that changes require you to do two hours' (or more) worth
of code research to make sure that the change won't break anything.

The real, real-world value of objects is that they allow you to make
more guarantees about how your code works, and package up things that
"belong together" in nice little bundles... so that two months or two
years from now when you (or someone else) comes to make changes to the
code, you can easily find where to make the change and you can make the
change secure in the knowledge that you're not breaking something
somewhere else.

This was what was "wrong" with procedural programming: it was not that
it wasn't expressive enough. C can express anything that C# can
express. The problem was that the language didn't help you organize
your code so that it was easy to understand and change. Before I
learned C++ and C#, I was writing "objects" in C. Why? Because
experience had taught me that this created more maintainable code than
did the usual procedural style of programming. When C++ came along, and
then C#, I was happy that the language finally helped me do what I had
been doing without any help for 10 years.

So, in the end all I can say is that if you finish writing your program
and say, "I don't see what the big deal about objects is," then you're
making a premature evaluation. You need to write your code then come
back and change it again, and again, and again. Only then will you
start to see that it's all about organizing your software, and it's far
easier to change software in which everything to do with a customer is
there, in the Customer object, than it is to change software in which
customer data is manipulated all over the place.

In the end, it's just an organizational convenience that, like all
other changes in the way we organize software, forces you to think
about problems in different ways.

As well, O-O programming long ago passed the
"flash-in-the-pan-marketing-fad" phase of its existence... and it's
still around and used widely. That tells me that it has great value.
Programmers are not idiots. They use what works, and what doesn't work
eventually dies. O-O addresses some important maintenance and
programming issues, otherwise we would have chucked it ten years ago.
 
Hi Bruce,

This is a very good description. I wish that I could have said it as well.

Thanks,
--- Nick
 
Hello TCE,

There is one more thought that I haven't seen mentioned among your
responses. I consider this to be the most important reason for using
objects to represent structures that encapsulate an idea...

Communication

Very very few projects anymore can be completed, in a reasonable timeline,
with only one person working on it. We work in teams, often sizeable teams.
We need to communicate very efficiently. To do that, we've invented
literally thousands of concepts and terms, all of which help this along.

If I use the phrase "processor bound" to refer to an algorithm, you would
(hopefully) think that I am talking about an application where the limiting
factor on performance is the speed and availability of CPU cycles, as
opposed to memory, hard disk space, bus speed, port speed, etc. Similarly,
if I use the term "Data Access Layer," you can think of a "group" of classes
or code within an application that handles the impedence between the
relational storage mechanism of our databases and the hierarchical
representation typically used in application memory.

Common terms allow us to communicate at a higher level, to share ideas
effectively, and to get to the point.

Object Oriented programming is not about objects. Those are simply the
shape of the tools. OOP is about communicating at a higher level by
creating a concept surrounding an implementation, and encapsulating the
implementation within a set of objects.

The simple form of this idea is obvious: objects that represent "things."
However, we have moved up from there, to create a series of expressions that
describe how we can create sets of objects that work together. These
expressions are called design patterns, and they have names.

A design pattern is not an algorithm. It is not like a finely tuned bubble
sort or a special way to handle collections. It is a description of how
"design" problems present themselves and how they can be solved in a
managable and maintainable manner using objects. You don't share snippets
of code, except as examples. You share the idea, the concept, and the name
that is attached to it.

These terms are added to the lexicon. Just like we use "Data Access Layer"
to describe a solution within an applications program structure, we can use
names like "Strategy pattern," "Abstract Factory," and "Chain of
Responsibility" to refer to constructs that allow us to solve design
problems.

It takes years to learn to use these terms effectively. There is an entire
series of books dedicated to describing standard patterns (far beyond those
described by Microsoft in their Patterns and Practices literature, which is
mostly a tiny set of implementation-specific patterns). The books are so
widely used that they are referred to by abbreviated terms.

The grand-daddy of the patterns books is called "Design Patterns: Elements
of Reusable Object Oriented Software" by Gamma, Helm, Johnson, and
Vlissides. The authors are referred to as the "Gang of Four" so you will
hear the book cited as merely [GoF]. It is a difficult book to read, but it
started a landslide. Other books from Buschmann, Fowler, and others have
followed. I referred to one of these books: "Design Patterns Explained" by
Shalloway and Trott, in an earlier reply to one of your postings.

In fact, just for you, I created a list of some of these books on Amazon.
http://www.amazon.com/exec/obidos/t.../ref=cm_aya_lm_title.more/103-9848276-2065456

It is not possible, in a newsgroup posting, to describe an entire practice
of software development. I hope only to have awakened your curiosity.

At the end of the day, it's the ability to communicate at this higher level
that makes it worthwhile to use OO design. In other words, in programming,
as in life, it's all about the people.

Hope this helps,
--- Nick
 
Back
Top