Hi David,
You are correct to want to understand what your tools are before attempting
to use them. In OOP, understanding what classes are is as important as
knowing what Integers are. After all, a class is a data type, just as an
Integer is. It wouldn't make much sense to use Integers if you didn't know
anything about them. You might just as well walk onto a construction site,
pick up a hammer gun, and inject a nail into your foot, eh?
A class is a definition for a data type. Data falls into 2 broad categories:
State and Process. A function is also a data type. It is a Process. It
manipulates data and returns a value. It executes. An Integer, on the other
hand, is State. It is a storage of data that is not process, but simply
data, such as the number 1.
A structure is a primitive data type that can hold both State and Process.
It can have members which are data, and members which are functions or
procedures. The structure is actually the ancestor of the class. It is the
first data type that was designed to hold both State and Process.
A class is an object-oriented structure. It holds both State and Process. It
has additional object-oriented characteristics , just as everything else in
OOP does. It has inheritance, polymorphism, encapsulation, etc. So, while
you can't inherit a structure, and derive another structure from it, you
certainly CAN inherit a class and derive another class from it.
All classes in .Net inherit (at least) System.Object. System.Object has the
bare minimum of what is needed to define a class. The beauty of OOP is that
you can define a base class which has all the characteristics common to a
whole "class" of classes, and define each of the classes as inheriting the
base class, eliminating the need to duplicate all of the code in the base
class. So, the CLR, for example, looks much like a tree, with System.Object
at the root, and a whole plethora of derived classes branching out from
there.
So, when to use a class? Well, if you've done procedural programming for
awhile, you should be aware that, from time to time, multiple functions need
to do the same types of operations. When this happens, rather than
duplicating code all over the place, you create another function that
performs the common task, and call it from your other functions.
The idea of a structure, which is procedural in nature, is that not only do
multiple functions sometimes need to perform the same types of operations,
sometimes they need to perform the same types of operations on the same
data, or the same types of data. A structure, which stores both State and
Process, fills the bill. OOP is simply an extension of procedural
programming, in which things are more encapsulated. In a procedural program,
you don't have (or have as easily) a mechanism for inheritance. In OOP, you
do. You have classes.
Designing classes requires an understanding of OOP, especially inheritance.
Good class design can reduce the amount of code that you work with (and
debug), and simplify your code overall, making it much easier to debug and
maintain. The basic principle to pay attention to is looking for duplicated
code, data, or functionality. When you see 2 blocks of code doing similar
things, you should suspect that some classes might be in order.
Of course, there's a lot more to designing classes than that. OOP isn't
called "object-oriented" for nothing. Generally, for example, a class holds
State and Process that are related in some way. In other words, classes are
logically structured. You wouldn't, for example, create a File IO class, and
have it execute a database operation. That would be like putting your shoes
in the refrigerator. Yes, the refrigerator is just fine for storing shoes,
but how are you going to remember that the refrigerator is where you put
them? A swiss army knife is a handy little gadget to have, but if it was
much larger, you might never find the nail clippers!
As for when to use them, well, if you're coding with .Net, you already are!
The CLR is nothing but a huge class library.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.
"David Lozzi" <dlozzi@(remo ve-this)delphi-ts.com> wrote in message
news:OC******** ******@TK2MSFTN GP14.phx.gbl...
Howdy,
I've discovered how to create and use a class in ASP.NET. However, when is
the best time to use a class? For example, I am currently using session
variables to store user information (user id, user name, full name, security
level, department, etc.). Would I do better to create a class instead? Also,
if I did, would I simply store the ID in the session and when accessing the
class (User.FullName, User.SecurityLe vel, etc.) then check the database? I'm
not sure what the best route is.
thanks.
--
David Lozzi
Web Applications/Network Specialist
Delphi Technology Solutions, Inc.
dlozzi(remove-this)@delphi-ts.com
