Printable View
Hey,
I'm developing a program in which there are two classes. The purpose of one of them is to create vectors that change dinamically (class A) and the other is a bunch of methods to operate on these vectors (class B).
The question is: I don't see any need to define a constructor in class B. In fact, I just define an object of class B, in main(), to access to the methods within it.
Is there any problem to not define a constructor, but using an object to just access to those methods?
Thanks
Why have 2 classes, then ?Quote:
Originally Posted by rocksoad23
Either put everything in the same class... or have B inherit from A.
Technically, it's okay...but smells like a bad design to me.Quote:
The question is: I don't see any need to define a constructor in class B. In fact, I just define an object of class B, in main(), to access to the methods within it.
Is there any problem to not define a constructor, but using an object to just access to those methods?
Can you post the code?
Your design strikes me as muddled.
Why would you want a separate class B with operations that act on data from class A? [This is along the same lines as manasij's query about having two classes rather than one].
If the only purpose in instantiating class B is to get access to functions that affect another class, why is B a class? Can it just be a namespace? If it is a class, can the member functions be static?
Is each instance of class A managing its own data, or class A only being instantiated in order to get access to functions that affect shared data? [If the latter, the same questions I asked about class B are also pertinent to class A].
OO design, incidentally, does not mean that all functions have to belong to a class. It usually means that classes and objects are a means of localising techniques for managing particular types of data.
Class B has the responsability to, given two vectors, simulate a physical system which its development depends exclusively on B's methods, whereas class A has just the function to create vectors that could be use in other class! In other words, class A and class B are totally independent, and it wouldn't makes sense if I defined all B's methods into A, because A creates any vectors that can be used by other class. A's functionality isn't simule that system, but just create vectors, whereas B has the responsability of simulate the physical system itself.Code:
class A {
[variables, methods' prototypes that create vectors which their memory can change dinamically when it is convenient]
};
[Definition of the constructor]
[Definition of those methods]
class B{
public:
A s(A&);
void f( long in);
void g (A&, const string&);
void h(A&, long int);
void i(A&,long int);
};
In my opinion, defining a program like that, it is much more structured and consistent, and totally oriented-object programming.
At first, I had all B's methods in A, thinking as you are telling me. But my teacher said to me that it is completly dumb to define the things like that, it's not structured and takes away all the object-orient logic.
It is the opposite, in my opinion.Quote:
Originally Posted by rocksoad23
This design takes away all object orient logic.
The main theme of OOP is to encapsulate data and provide an interface of methods to manipulate that data, in a single container.
Separating them out like this makes little sense (and is analogous to a perfectly healthy human needing a crutch) .
Well, if you think that is OO, you don't understand what OO is about. You're making the classic newbie mistake of believing that every operation has to be a member function of a class or object.
From what little information you have provided, all class B is providing is an alternative interface to class A. I suspect that all of B's methods are just thin wrappers for methods in class A. For example, B::g() might look something like
so an instance of class B is not adding any value. This suggests B::g() can be a static function (no instance of B to worry about), or even a namespace (rather than a class) as I alluded in previous questions.Code:void B::g(A&a, const string &s)
{
a.set_some_string(s);
}
Personally, I would eliminate class B entirely. The functions don't have to be members of any class, so can be specified as such.
Java background, right?
I know, and it was my first thinking about it: okay, let's define a class with all the methods inside that allow me to define vectors and methods to use, either to manipulate dinamically the vectors either to operate on them creating the physical system environment.Quote:
Originally Posted by manasij7479
But what my professor said makes sense, I think. Why should A's class has methods to simulate a system, if the purpose of this class is not do it, but to just create vectors. Why should I incorporate concrete methods in A, if they have nothing to do with creating vectors?
Classes do not have purposes in that sense.Quote:
Originally Posted by rocksoad23
A class defines a type...and its objects are things.
Here your 'vectors' are things.
It makes sense that the things know about themselves and do not have to use some proxy object for all functionality.
Sure there is some argument whether your functions should be member functions or free functions, but your current way is roundabout.
Also, read up on the Factory Design Pattern.
You should never feel compelled to write a constructor for no good reason. You only create a constructor if you need the class to have one. Same goes for the other auto-generated methods, most of the time.