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
--
http://www.csharp-station.com

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:en3VLXU4EHA.3336@TK2MSFTNGP11.phx.gbl...

[quoted text, click to view]

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

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:en3VLXU4EHA.3336@TK2MSFTNGP11.phx.gbl...
[quoted text, click to view]

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

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

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:en3VLXU4EHA.3336@TK2MSFTNGP11.phx.gbl...
[quoted text, click to view]

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

"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:uamAOMc4EHA.1396@tk2msftngp13.phx.gbl...
[quoted text, click to view]

Hi Nick,

Thanks for the suggestion. I'll take a look.

tce

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.