Hi Mike,
I can certainly understand that. This issue (production versus research) is
one which all good programmers grapple with. Here's a short summary of a
Reader's Digest Condensed version of the issues involved in class design.
Abstraction may be the single most important aspect of OOP. With procedural
programming, code is thought of as instructions that are executed in a
sequence. Often it is broken down into groups of instructions (functions,
for example) that are executed in sequence. However, there is also data
involved, numbers, text, dates, etc., in many forms (variables, constants,
structures, arrays, etc.). This breaking apart of code into sections became
important for the sake of reducing redundant code, making code more
readable, etc.
In OOP, this sectioning is taken a step farther, via, among other things,
abstraction. Abstraction is the process of conceiving these blocks of
process and data as objects, machines, tools, or other "real-world"
concepts. They do, after all, behave as if they were "real-world" objects.
For example, a set of functions for doing math behaves much like a
calculator. Note that I mentioned "a set of functions." A class is a set of
processes (functions) and data that are designed to interact or be related
in some way. This not only extends the idea of reduction of redundant code,
but makes larger systems more manageable and organized.
So, the first thing to do is master the art of thinking of processes and
code as real-word objects.
Encapsulation is the idea that certain data and process need to be
accessible to a limited number of other processes and data. The various
access modifiers for classes, functions, and other class members provide
this ability. It hides the inner mechanics of the engine of the car from
everyone but the guy who knows how to work on it, and the other car parts
that need to interact with it, and exposes the driving interface of the
engine to people that need to drive it.
Polymorphism is the ability to re-purpose certain types of classes or
objects, for a variety of related tasks. A Military HumVee, for example, can
have a variety of tops mounted on it, and a variety of accessories installed
on it, in order to repurpose it for any type of vehicle task, from driving
people around, to being an ambulance, a small truck, or a mobile rocket
launcher, to name a few. Well-designed classes can be repurposed in a
similar way, through a variety of features of the OOP toolset.
Inheritance is the ability to create a base class that provides process and
data that is common to a variety of conceivable classes. Each class that
inherits the base class is, in effect, the base class, but can have
additional code added to repurpose it for a specific type of functionality.
Take System.Web.UI.Control, for example. This base class contains the
process and data that are common to all Web Interface Controls. It provides
the basic functionality of a Control, the ability to "draw" HTML, contain
other UI Controls, respond to and raise UI events, etc. Each Web UI Control
inherits System.Web.UI.Control, but creates a different type of user
interface for a different purpose.
Keeping these principles in mind, you should seek to design your classes
along the same lines. Don't think of them as containers for a bunch of code.
Think about the code that is in them, what it does, what it has in common
with other code, how you may want to re-use it in this or another project,
and design your class structures appropriately.
This does take a good bit of thought, and a good bit of time. But one of the
principles of OOP is that a little extra time spent up front in the desing
mode save a lot of time down the road.
In the meantime, as you have to produce, don't get overly anal about it. You
can always improve your designs later. Any good developer does. Find your
own balance. And keep asking good questions!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
"mharness" <bo***@hotmail.com> wrote in message
news:KI********************@comcast.com...
Hello Kevin
I appreciate the recommendation but to be honest, I need to produce more
now than I need to learn. Why don't you give the short answer a try?
Thanks
Mike
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...I would recommend studying OOP, so that you know why classes are used in
the first place, and design them accordingly. They are not simply
containers for code. OOP incorporates Inheritance, Abstraction,
Polymorphism, and Encapsulation for a lot of very good reasons. If you
study up on these, you'll be amazed at what they can be used for.
--
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.
"mharness" <bo***@hotmail.com> wrote in message
news:Mt********************@comcast.com... Hello All,
I've defined a number of classes that currently only include public
variable declarations. I've been reluctant to add subroutines and
functions for fear of taking a performance hit when I pass the class as
an argument to another function and in a one case, store the class to a
session variable.
Right now I have all of my functions and subroutines in a single class
that's becoming a bit unwieldy. What I'd like to do is move all of the
form-specific f&s to the classes that are specific to the respective
forms.
Any reason why I shouldn't?
Many thanks,
Mike
