object-oriented issue - when to use classes

Hi,
I have a question regarding the object-oriented issue. I understand
that a class is a type. I have an array class. Now say that I want
to implement an algorithm A that uses the array class. Does it make
sense to make a class for the algorithm such as

class MyAlg
{
private:
Array A1;
Array A2;
// more data members

public:
// my functions
};

Right now I have my algorithm as an interface to the Array class (i.e.
just a bunch of global functions). The problem is that it gets pretty
messy and unorganized since there are so many parameters associated
with the algorithm. Since I now added a GUI for my algorithm, I
thought that maybe if I wrap my algorithm in a class, the code will be
cleaner. So in short, my current design is 3-tiered:

GUI -> My algorithm as a set of global functions -> Array class
implementation

I want to make it into a 2-tier design:

GUI -> My algorithm as a class (with Array contained in this
class)

Can someone please tell me if this is the right way to do it? I am
puzzled because it doesn't sound semantically correct -- since the
algorithm is not really a TYPE, but rather a method. If I shouldn't
define a class for it, what are my alternatives? I just don't feel
that using a bunch of global functions is the way to go. Thanks a
lot!

Jessica

re: object-oriented issue - when to use classes

Jessica <jesssi1203@yahoo.com> wrote in message
news:76acb828.0307171553.339f93d7@posting.google.c om...[color=blue]
> Hi,
> I have a question regarding the object-oriented issue. I understand
> that a class is a type. I have an array class. Now say that I want
> to implement an algorithm A that uses the array class. Does it make
> sense to make a class for the algorithm such as
>
> class MyAlg
> {
> private:
> Array A1;
> Array A2;
> // more data members
>
> public:
> // my functions
> };
>
> Right now I have my algorithm as an interface to the Array class (i.e.
> just a bunch of global functions).[/color]

If it's an interface to the Array class then it's not a bunch of global
functions. Someone else recently called member variables 'global'. Is there
a teacher out there teaching the wrong meaning of 'global'? Global functions
are those that are not inside a class and can be called from anywhere.
[color=blue]
> The problem is that it gets pretty
> messy and unorganized since there are so many parameters associated
> with the algorithm. Since I now added a GUI for my algorithm, I
> thought that maybe if I wrap my algorithm in a class, the code will be
> cleaner. So in short, my current design is 3-tiered:[/color]

I hope this means that your GUI code is completely separate from your
algorithm code.
[color=blue]
> GUI -> My algorithm as a set of global functions -> Array class
> implementation
>
> I want to make it into a 2-tier design:
>
> GUI -> My algorithm as a class (with Array contained in this
> class)
>
> Can someone please tell me if this is the right way to do it?[/color]

It's hard to tell without more details. If your algorithm has many inputs,
and some of these are the same while others vary, then it's a good candidate
for a class. Otherwise a single function (a _real_ global function) might be
the most appropriate, regardless of the number of inputs. A class would have
the advantage for some algorithms of being able to do optimizations, such as
caching certain intermediate values. For instance, a FastFourierTransform
object could pre-calculate an array of sines and cosines, or whatever it
needs, for a given number of points, which can then be used until the number
of points changes.

If possible, it's best not to limit an algorithm to using something like
Array objects. If your array is a simple Array of doubles, for example, then
it would be better for your algorithm to take pointers to doubles, e.g.,
void someAlgorithm(const double *begin, const double *end, /* other
parameters */);

Then you can use any kind of array of doubles, e.g.,
void f()
{
std::vector<double> v;
// fill vector with numbers
someAlgorithm(v.begin(), v.end(), /* other parameters */);
}

Try to make your algorithm is flexible as possible, rather than limiting its
use to such specific types as Array.

I agree that your algorithm should not be in the Array class. Again, that
would be a very-specific, very limiting design. Arrays should just be
containers.

Do you have a good reason for using your own Array class rather than a
container supplied by the standard library?

DW

re: object-oriented issue - when to use classes

Jessica wrote:
[color=blue]
> I have a question regarding the object-oriented issue.
> I understand that a class is a type.
> I have an array class. Now say that
> I want to implement an algorithm A that uses the array class.
> Does it make sense to make a class for the algorithm such as
>
>
> class MyAlg {
> private:
> Array A1;
> Array A2;
> // more data members
>
> public:
> // my functions
> };[/color]

I presume that your Array is some kind of container class.
What kinds of elements does your Array contain?
Your description is vague and that's a bad sign.
[color=blue]
> Right now I have my algorithm as an interface to the Array class
> (i.e. just a bunch of global functions).[/color]

That's just fine and necessary if those functions implement *methods*
that apply to objects of type Array. It might be a good idea
if your "global" functions belonged to a namespace instead.
[color=blue]
> The problem is that it gets pretty messy and unorganized
> since there are so many parameters associated with the algorithm.
> Since I now added a GUI for my algorithm, I thought that
> maybe if I wrap my algorithm in a class, the code will be cleaner.
> So in short, my current design is 3-tiered:
>
> GUI -> My algorithm as a set of global functions -> Array class
> implementation
>
> I want to make it into a 2-tier design:
>
> GUI -> My algorithm as a class (with Array contained in this
> class)
>
> Can someone please tell me if this is the right way to do it?
> I am puzzled because it doesn't sound semantically correct --
> since the algorithm is not really a TYPE, but rather a method.
> If I shouldn't define a class for it, what are my alternatives?
> I just don't feel that
> using a bunch of global functions is the way to go.[/color]

Suppose that your Array is actually an array of numbers -- a vector.
You probably want a *free* function that can perform
a Direct Discrete Fourier Transform (DDFT) on a complex vector

Array x(n);
Array y = ddft(x);

But you may also want to define DDFT object
that you can apply repeatedly to vectors of a given size
the way that FFTW does (http://www.fftw.org/).

Array x(n);
DFT ddft(n, -1);
Array y = ddft(x);
Array z = ddft(y);

Matrix decompositions are also a good candidate for this approach.

Take a look at
The C++ Scalar, Vector, Matrix and Tensor Class Library

http://www.netwood.net/~edwin/svmtl/

Visit The Object-Oriented Numerics Page

http://www.oonumerics.org/oon/

for lots more good information

re: object-oriented issue - when to use classes

"Jessica" <jesssi1203@yahoo.com> wrote in message
news:76acb828.0307171553.339f93d7@posting.google.c om...[color=blue]
> Hi,
> I have a question regarding the object-oriented issue. I understand
> that a class is a type. I have an array class. Now say that I want
> to implement an algorithm A that uses the array class. Does it make
> sense to make a class for the algorithm such as
>
> class MyAlg
> {
> private:
> Array A1;
> Array A2;
> // more data members
>
> public:
> // my functions
> };
>
> Right now I have my algorithm as an interface to the Array class (i.e.
> just a bunch of global functions). The problem is that it gets pretty
> messy and unorganized since there are so many parameters associated
> with the algorithm. Since I now added a GUI for my algorithm, I
> thought that maybe if I wrap my algorithm in a class, the code will be
> cleaner. So in short, my current design is 3-tiered:
>
> GUI -> My algorithm as a set of global functions -> Array class
> implementation
>
> I want to make it into a 2-tier design:
>
> GUI -> My algorithm as a class (with Array contained in this
> class)
>
> Can someone please tell me if this is the right way to do it?[/color]

I think you are on the right track. If I am not terribly mistaken, I have
seen a similar technique in Bjarne Stroustrup's book "The C++ Programming
Language, 3rd edition", chapter 18.4 "Function Objects".
[color=blue]
> I am
> puzzled because it doesn't sound semantically correct -- since the
> algorithm is not really a TYPE, but rather a method.[/color]

I think it is semantically correct -- Let's imagine a complicated algorithm
which uses Array A1 and A2 to convert doubles into strings:
you could supply std::string operator()(double) to your class 'MyAlg'. This
operator() could then implement any algorithm operating on the internal
Array A1 and A2 data members. You then create an object of class 'MyAlg'
(let's say, for example 'MyAlgObj'):

MyAlg MyAlgObj;
std::cout << "The first string representation is: " << MyAlgObj(-5.547) <<
std::endl;
std::cout << "The second string representation is: " << MyAlgObj(76.002) <<
std::endl;

Not only does MyAlgObj look like a function, it also behaves like a
function. This seems Ok to me and is a very powerful technique to implement
algorithms. However, I don't know whether this technique can be called
object-oriented.
[color=blue]
> If I shouldn't
> define a class for it, what are my alternatives? I just don't feel
> that using a bunch of global functions is the way to go. Thanks a
> lot!
>
> Jessica[/color]

re: object-oriented issue - when to use classes

> I have a question regarding the object-oriented issue. I understand[color=blue]
> that a class is a type. I have an array class. Now say that I want
> to implement an algorithm A that uses the array class.
>Does it make sense to make a class for the algorithm such as[/color]

In terms of encapsulation: yes. But look at the generic
functions found in C++ like copy, sort, unique, transform etc.
These are all functions that operate on STL-containers but do
not belong to a class themselves. They take classes as arguments,
usually iterators, but are 'global' themselves.

Try to make your 'global' functions more general so that they
work on class hierarchies. There is nothing wrong with a few
globals. Your function main() will always be global, for instance.

-X

re: object-oriented issue - when to use classes

jesssi1203@yahoo.com (Jessica) wrote in message news:<76acb828.0307171553.339f93d7@posting.google. com>...
[snip][color=blue]
> Can someone please tell me if this is the right way to do it?[/color]

When it comes to doing algorithms with classes, especially
container classes, you'd be working pretty hard to beat how
the standard library does it. Get yourself a good book on
how to do the standard lib and see how they've done it.
Here is a link to a review of one such good book.

http://www.accu.org/cgi-bin/accu/rvo...file=cp003310a

Of course, that's only one approach.
Socks

re: object-oriented issue - when to use classes

Hi David,

Thanks for your wonderful inputs (as well as those who replied)!
However, I think you misunderstood my posting.. Perhaps I didn't
phrase it very carefully. When I said "global" functions, I really
meant global functions. The class declaration (MyAlg) I wrote here is
what I intended to do, but haven't actually done it. Currently the
only class I have is the Array class which, by the way, is just a
wrapper class for the STL vector. My algorithm is a bunch of
functions in a separate file. I call them global because they don't
belong to any classes. My GUI then calls those functions, so I guess
I can say that the GUI is well separated from the algorithm code.

Sorry if I didn't make my original posting more clear. I truely
appreciate your help -- I just felt the need to defend myself since my
teachers should not be the ones to blame for my vague postings.

Jessica


"David White" <no@email.provided> wrote in message news:<F9IRa.722$sI.35328@nasal.pacific.net.au>...[color=blue]
> Jessica <jesssi1203@yahoo.com> wrote in message
> news:76acb828.0307171553.339f93d7@posting.google.c om...[color=green]
> > Hi,
> > I have a question regarding the object-oriented issue. I understand
> > that a class is a type. I have an array class. Now say that I want
> > to implement an algorithm A that uses the array class. Does it make
> > sense to make a class for the algorithm such as
> >
> > class MyAlg
> > {
> > private:
> > Array A1;
> > Array A2;
> > // more data members
> >
> > public:
> > // my functions
> > };
> >
> > Right now I have my algorithm as an interface to the Array class (i.e.
> > just a bunch of global functions).[/color]
>
> If it's an interface to the Array class then it's not a bunch of global
> functions. Someone else recently called member variables 'global'. Is there
> a teacher out there teaching the wrong meaning of 'global'? Global functions
> are those that are not inside a class and can be called from anywhere.
>[color=green]
> > The problem is that it gets pretty
> > messy and unorganized since there are so many parameters associated
> > with the algorithm. Since I now added a GUI for my algorithm, I
> > thought that maybe if I wrap my algorithm in a class, the code will be
> > cleaner. So in short, my current design is 3-tiered:[/color]
>
> I hope this means that your GUI code is completely separate from your
> algorithm code.
>[color=green]
> > GUI -> My algorithm as a set of global functions -> Array class
> > implementation
> >
> > I want to make it into a 2-tier design:
> >
> > GUI -> My algorithm as a class (with Array contained in this
> > class)
> >
> > Can someone please tell me if this is the right way to do it?[/color]
>
> It's hard to tell without more details. If your algorithm has many inputs,
> and some of these are the same while others vary, then it's a good candidate
> for a class. Otherwise a single function (a _real_ global function) might be
> the most appropriate, regardless of the number of inputs. A class would have
> the advantage for some algorithms of being able to do optimizations, such as
> caching certain intermediate values. For instance, a FastFourierTransform
> object could pre-calculate an array of sines and cosines, or whatever it
> needs, for a given number of points, which can then be used until the number
> of points changes.
>
> If possible, it's best not to limit an algorithm to using something like
> Array objects. If your array is a simple Array of doubles, for example, then
> it would be better for your algorithm to take pointers to doubles, e.g.,
> void someAlgorithm(const double *begin, const double *end, /* other
> parameters */);
>
> Then you can use any kind of array of doubles, e.g.,
> void f()
> {
> std::vector<double> v;
> // fill vector with numbers
> someAlgorithm(v.begin(), v.end(), /* other parameters */);
> }
>
> Try to make your algorithm is flexible as possible, rather than limiting its
> use to such specific types as Array.
>
> I agree that your algorithm should not be in the Array class. Again, that
> would be a very-specific, very limiting design. Arrays should just be
> containers.
>
> Do you have a good reason for using your own Array class rather than a
> container supplied by the standard library?
>
> DW[/color]