Hi Scott,
Well, it sounds like you're on the right track, believe it or not. You have
to look at the evloution of programming to understand it more clearly.
In the beginning (almost), code was simply instructions that were executed
in the order in which they appeared in the source. It was soon discovered,
however, that certain blocks of code were commonly executed again and again.
This was initially solved with GoTo statements, which instructed the
compiler to go to a certain location in the code, execute the instructions
there, and return to the point it left from. And this lasted a while.
As the size and complexity of programs grew, GoTo statements made for some
serious spaghetti code, which became hard to maintain and modify. The
concept of more ordered source code, using functions and sub-procedures was
introduced to make code easier to manage.
Of course, this convenience only lasted awhile, as programs grew more in
complexity, and multi-tasking operating systems were introduced. Believe it
or not, Windows 3.1 was written in C, not C++. It used a heck of a lot of
loops and nested loops to do multi-tasking, messaging, and so on. You can
imagine the difficulty in maintaining such a huge program, which was made up
essentially of a single set of instructions that was immense in size.
At this point, due to the complexity of programs, new data types were
introduced called "structures ." A structure is simply a combination of
multiple data and types of data into a single unit. It made code
organization easier, and a structure could hold both State and Process. In
other words, a member of a structure could be a piece of data, such as an
integer, or it could be a process, such as a function. Are we starting to
sound a little familiar at this point? We should be.
Enter Object-Oriented programming. Structures evolved into
objects/types/classes. OOP enhanced the structure concept, and added a few
of its own:
Inheritance: Inheritance performs much the same function as functions and
sub-procedures in terms of what its purpose is. By defining a base class,
and inheriting it, one could build multiple classes that shared some of the
same state and process, but with additional characteristics as well. In
addition, the developer doesn't have to re-write the same code to create a
new class. The code in a class is relatively lean, as much of the code
resides in the base class. This makes code maintenance and debugging much
easier.
Encapsulation: OOP introduced the idea of hiding members of a class in a
variety of ways. By doing so, the possible errors that could occur were
minimized. Only the members necessary to access fro outside the class are
exposed. There is no way that something outside the class can modify
something that it should not. This also enhances code maintenance and
debugging, by reducing the number of variables that can affect performance
of the app.
Polymorphism: Plolymorphism was actually introduced in earlier procedural
languages, with the concept of overloaded functions, by defining a function
as accepting different data types, and behaving differently when using them.
Classes extend the concept with overrides and other similar mechanisms that
allow a class to behave differently in different circumstances.
Abstraction: A little harder to define. Abstraction is an outgrowth of
encapsulation, in a sense. By hiding the details of how an object performs
its tasks, other objects can treat the class as if it were a "machine" that
performs some task, rather than a set of instructions. This also simplifies
code creation and maintenance.
All of this has come about as a result of computer and software evolution.
Just as Assembler language was developed to reduce the amount of time
necessary to write an application in machine code, each evolutionary stage
of programming technology is designed to reduce the amount of time and
resources necessary to write, debug, and maintain software.
The better your object model, the easier and quicker you can write
applications with it. If you're wise, you will create re-usable classes that
will continually reduce the amount of time and effort spent in future
development.
So, in conclusion, what is gained by OOP is the same thing that is gained
with "just using procedural techniques to group related functions together
into modules." It is simply the next stage in the evloution of programming.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"scottrm" <sc*****@newsgr oup.nospam> wrote in message
news:4A******** *************** ***********@mic rosoft.com...
I am fairly new to oo design and I am looking at developing an object
oriented asp.net application which will be built on top of a relational
database. I have read quite a bit of the theory but find it hard to put it
into practice. In particular I am confused in terms of interacting with
the
database. It seems to me classes map quite closely to database tables and
I
end up with a bunch of methods in each class which simply call stored
procedures to do data access eg. AddOrder method in an Order class. In
that
case oo design just seems like a wrapper on top of the database. I don't
see
what is gained over just using procedural techniques to group related
functions together into modules. I am sure I am missing something.
Any pointers to get on the right track? Specific advice or samples of a
good design would be more appreciated that a pointer to a general book
(although if someone knows of something dealing with this specific problem
that would be great.)
--
Scott
