object oriented design

G

Guest

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.)
 
K

Karl Seguin

Scott,
I don't think you are missing anything. For simple systems your database
does map very closely to your objects and you do end up with a lot of code.
Some solutions to this are to use (a) a code generation tool (google search
CodeSmith) and (b) a professional O/R mapper (google search WilsonOR)

I love codesmith :)

Anyways, back to the topic..the benefit you gain with OO is more noticable
as your system grows complex. You'll see that your relational data doesn't
map so well to your object world (google search Object-Relational impedence
mismatch). A classic example is inheritance which brings forth tremendous
benefits that you can't get from a more procedural technique.

A solution might be to use a Data Mapper Design pattern
(http://www.martinfowler.com/eaaCatalog/dataMapper.html). This would leave
your classes as more pure domain objects and move the mundane and repetivie
mapping to its own layer/class. Great for even more flexibility.

If you aren't taking advantage of encapsulation, abstraction, inheritance
and polymorphism in your classes, ask yourself if you could..or think ahead
and see if they might be necessary with future requirements. Chances ar the
flexibility you've given yourself by this approach will pay off for itself
....even if it seems a little straightforward now..

Karl
 
P

Peter Morris [Droopy eyes software]

Although it is quite hard to learn initially, Enterprise Core Objects from
Borland is an excellent tool.

You design the model in UML, it generates the DB for you, and you work only
with objects (never the db).

My website howtodothings.com was written with it, and I don't have a single
SQL statement in the whole project.



--
Pete
====
Read or write articles on just about anything
http://www.HowToDoThings.com

My blog
http://blogs.slcdug.org/petermorris/
 
K

Kevin Spencer

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.
 
F

fd123456

Hi Scott,

On top of what's been said, the fact that your db classes are just
wrappers for the db allows for a very academic N-Tiers architecture.
Down the road, N-Tiers is (are?) safer and less error-prone.

PS : and if you read Kevin's answer, you'll see that oo teaches you to
be both synthetic and crystal-clear. Nice piece, Kevin.

HTH,

Michel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top