Thread: Defining a Constructor

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.

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);
};

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.
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.

Originally Posted by rocksoad23

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.
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

Code:

void B::g(A&a, const string &s)
{
    a.set_some_string(s);
}

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.

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?

Originally Posted by rocksoad23

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.
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.