By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,732 Members | 860 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,732 IT Pros & Developers. It's quick & easy.

how to best use classes

P: n/a
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
Nov 19 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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

Nov 19 '05 #2

P: n/a
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


Nov 19 '05 #3

P: n/a
Is your need to "produce" now more important than throwing the code away in
the near future because you've completely mis-used classes in your
implementation?

Classes represent a definition of a melding of code *and* data. For example,
a PersonRecord class might have data comprising the fields (from an RDBMS)
making up one person, but also methods (code) to write that data to the
database, read data from the database, etc.

Inheritance lets one class inherit the data and code of another class.

Polymorphism is the principle of applying a common operation to many objects
(where the objects are all derived from a common Base class) - the operation
is common but the behaviour as a result of that operation is not. The
classic teaching example is a Shape class, and the derived classes Square,
Circle, Trianglee. Each shape has a Draw( ) method. When you draw a shape,
Square objects will draw their squares, circle objects will draw their
circles, and triangle objects will draw their triangles.

Encapsulation is the hiding of information within an object so it is private
to the object and not accessible to others outside it. The class definition
controls what is publicly accessible and what is not.

Having said this, I agree with Kevin Spencer - study OOP - it will be
nothing short of a revelation to you. You will pick up the concepts quickly.
You need to be able to recognise the implementation problems where the
various aspects of OO come to the rescue, and apply appropriately.

[Another] Kevin

"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



Nov 19 '05 #4

P: n/a
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



Nov 19 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.