Defining a Constructor

This is a discussion on Defining a Constructor within the C++ Programming forums, part of the General Programming Boards category; Hey, I'm developing a program in which there are two classes. The purpose of one of them is to create ...

  1. #1
    Registered User
    Join Date
    Dec 2012
    Posts
    7

    Defining a Constructor

    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

  2. #2
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by rocksoad23 View Post
    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).
    Why have 2 classes, then ?
    Either put everything in the same class... or have B inherit from A.
    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?
    Technically, it's okay...but smells like a bad design to me.
    Can you post the code?
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,307
    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.
    Right 98% of the time, and don't care about the other 3%.

  4. #4
    Registered User
    Join Date
    Dec 2012
    Posts
    7
    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.
    Last edited by rocksoad23; 12-09-2012 at 04:02 AM.

  5. #5
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by rocksoad23 View Post
    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) .
    Last edited by manasij7479; 12-09-2012 at 04:11 AM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  6. #6
    Registered User
    Join Date
    Jun 2005
    Posts
    6,307
    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?
    Right 98% of the time, and don't care about the other 3%.

  7. #7
    Registered User
    Join Date
    Dec 2012
    Posts
    7
    Quote Originally Posted by manasij7479 View Post
    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) .
    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.
    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?

  8. #8
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by rocksoad23 View Post
    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.
    Last edited by manasij7479; 12-09-2012 at 06:33 AM.
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  9. #9
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,304
    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.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 06-23-2012, 10:47 PM
  2. Replies: 5
    Last Post: 02-21-2011, 01:19 AM
  3. Specialized Constructor call Default Constructor
    By threahdead in forum C++ Programming
    Replies: 15
    Last Post: 08-23-2010, 03:39 PM
  4. Replies: 6
    Last Post: 05-19-2010, 04:03 AM
  5. Replies: 10
    Last Post: 06-02-2008, 08:09 AM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21