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/tg...848276-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
"thechaosengine" <sh856531@microsofts_free_email_service.com> wrote in
message news:ua**************@tk2msftngp13.phx.gbl...
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
