What should constructor do?
-
I am building my first class to output graphic to LCD connected to a micro. Making small progress, however, since there is no proccess feedback form the LCD itself I have to "wait" until something, anything , shows on the LCD. To test my code I opted to let the constructor paint the whole screen red. Now for silly question. I understand constructor function is to instantiate the class so the class methods can be used. In general most constructors in micro world just take care of very basic - I/O pins assignments, serial baud rate etc. Would it make more sense if I do all the painting OUTSIDE of constructor? Or is is just one of those "personal preferences" ? Eventually I will have more than one instance of this class running. Thanks , any comments are as always appreciated.
-
I am building my first class to output graphic to LCD connected to a micro. Making small progress, however, since there is no proccess feedback form the LCD itself I have to "wait" until something, anything , shows on the LCD. To test my code I opted to let the constructor paint the whole screen red. Now for silly question. I understand constructor function is to instantiate the class so the class methods can be used. In general most constructors in micro world just take care of very basic - I/O pins assignments, serial baud rate etc. Would it make more sense if I do all the painting OUTSIDE of constructor? Or is is just one of those "personal preferences" ? Eventually I will have more than one instance of this class running. Thanks , any comments are as always appreciated.
When using the class multiple times it will make of course sense to perform the output in it's own function. Otherwise each usage will initially draw the same. Even for testing you can call that function (it is just one function call after creating the class). While you can do anything you want in a constructor, it is often not utile. Because constructors did not return a value, you will often find an additional setup function that returns success/failure while the constructor only initialises members variables.
-
I am building my first class to output graphic to LCD connected to a micro. Making small progress, however, since there is no proccess feedback form the LCD itself I have to "wait" until something, anything , shows on the LCD. To test my code I opted to let the constructor paint the whole screen red. Now for silly question. I understand constructor function is to instantiate the class so the class methods can be used. In general most constructors in micro world just take care of very basic - I/O pins assignments, serial baud rate etc. Would it make more sense if I do all the painting OUTSIDE of constructor? Or is is just one of those "personal preferences" ? Eventually I will have more than one instance of this class running. Thanks , any comments are as always appreciated.
Vaclav_Sal wrote:
To test my code I opted to let the constructor paint the whole screen red.
Painting sounds like a behavior rather than a setup. Thus the constructor isn't where it goes.
Vaclav_Sal wrote:
in micro world
Far as I know micro coding tends to strongly favor execution efficiency. So that decides it. After that then for object oriented programming it follows the idiom that 1. The constructor does what must be done for the object to exist. If it fails then the object cannot exist. 2. Other than 1 everything else is behavior so a method not in the constructor. So if you can't paint the screen red is that a error or does it mean that caller is done and cannot and must not proceed?
-
Vaclav_Sal wrote:
To test my code I opted to let the constructor paint the whole screen red.
Painting sounds like a behavior rather than a setup. Thus the constructor isn't where it goes.
Vaclav_Sal wrote:
in micro world
Far as I know micro coding tends to strongly favor execution efficiency. So that decides it. After that then for object oriented programming it follows the idiom that 1. The constructor does what must be done for the object to exist. If it fails then the object cannot exist. 2. Other than 1 everything else is behavior so a method not in the constructor. So if you can't paint the screen red is that a error or does it mean that caller is done and cannot and must not proceed?
Thanks. It definitely makes sense to utilize methods return values, something I do most of the time anyway, and let the constructor just do very basic. As I mentioned, in the real case of LCD class, I do not have feedback from most of methods,so I need to change my debugging. Instead of blindly painting the whole screen I'll just paint one pixel ( which I probably won't be able to see) and than read it back. I guess I should walk before running, or better yet after falling down while running it is time to go back to walking.
-
I am building my first class to output graphic to LCD connected to a micro. Making small progress, however, since there is no proccess feedback form the LCD itself I have to "wait" until something, anything , shows on the LCD. To test my code I opted to let the constructor paint the whole screen red. Now for silly question. I understand constructor function is to instantiate the class so the class methods can be used. In general most constructors in micro world just take care of very basic - I/O pins assignments, serial baud rate etc. Would it make more sense if I do all the painting OUTSIDE of constructor? Or is is just one of those "personal preferences" ? Eventually I will have more than one instance of this class running. Thanks , any comments are as always appreciated.
-
I am building my first class to output graphic to LCD connected to a micro. Making small progress, however, since there is no proccess feedback form the LCD itself I have to "wait" until something, anything , shows on the LCD. To test my code I opted to let the constructor paint the whole screen red. Now for silly question. I understand constructor function is to instantiate the class so the class methods can be used. In general most constructors in micro world just take care of very basic - I/O pins assignments, serial baud rate etc. Would it make more sense if I do all the painting OUTSIDE of constructor? Or is is just one of those "personal preferences" ? Eventually I will have more than one instance of this class running. Thanks , any comments are as always appreciated.
If it clears things up at all.... If you ever write some C++ code using MFC (Microsoft's Foundation Class, essentially an OO wrapper around the WinAPI), you'll notice that there are always initialization routines aside from constructors (they're called OnInit...blah ). If you happen to use a dialog object, and attempt to draw from the constructor instead of the initialization routine, you'll notice that the objects exist but are not windows yet so you'll get an assertion (if running in debug mode). This means that the constructors have been called but nothing has been drawn yet. The drawing only occurs after all the constructors have been called, the initialization routines are systematically called after that and you can load all the widgets with whatever the default values to be displayed are. Moral of the story, drawing typically doesn't take place during construction of objects.