Hi Stalica, does the base class need virtual constructor in this method if there are other data also in the derived classes (Triangle, circle and square) ?
Never a bad idea to make destructors virtual so that way you guarantee the right destructor is executed for the right object if there is any chance for a class to be inherited from.
You could allocate the Factory object on the stack and use statically allocated memory to allocate instances of each object as attributes of the Factory. Then you could return any of them on demand. Something like that might work, but would be unusual.
If I understand the question, it's a matter of encapsulation and/or closely adhering to the object-oriented programming paradigm. Of course, rules can be broken, but it's going to depend on the requirements of your project and the overall resulting design you come up with. I prefer a consistent design, so if I'm going to do OOP, I'm going to do it all the way.
Thanks! Great explanation!
Hey, Daniel. Thanks for the beer, and glad you found it helpful!
Simply about hard stuff as for me, thank you very much!
You can do it!
Super explanation sir, Thank you!
Glad you liked it
Nicely explained.. Thank you very much
Amazing video, thank you so much! This helped me prep for my C++ code design interview:)
Oh, that's fantastic! I hope you get the job. Good luck! If you get it, you owe me a beer! 🍻😆
Excellent explanation.
Glad you think so!
Perfect sir. Thank you from INDIA. Subscribed to your channel.
Namaste!!
clear + simple = thank you so much
Glad it helped!
Hi Stalica, does the base class need virtual constructor in this method if there are other data also in the derived classes (Triangle, circle and square) ?
None of the classes need a virtual constructor.
@@ProfessorHankStalica sorry I was asking for virtual destructor
Never a bad idea to make destructors virtual so that way you guarantee the right destructor is executed for the right object if there is any chance for a class to be inherited from.
Can this design pattern work for objects created on the stack rather than on the heap
You could allocate the Factory object on the stack and use statically allocated memory to allocate instances of each object as attributes of the Factory. Then you could return any of them on demand. Something like that might work, but would be unusual.
Can I simply think that the create() method is similar to the getClass() in Java, which in C++ returns a 'this' pointer?
nice and clear video.
which advantage do you see in using a Factory class instead of a create(type t) method directly (i.e. a factory method)?
If I understand the question, it's a matter of encapsulation and/or closely adhering to the object-oriented programming paradigm. Of course, rules can be broken, but it's going to depend on the requirements of your project and the overall resulting design you come up with. I prefer a consistent design, so if I'm going to do OOP, I'm going to do it all the way.
Why not using template instead of enum? Is factory required to support RTTI?
Just because. There's many ways you could implement a factory pattern. This is one.
thank you so much
You are welcome so much.
Thank you
You're welcome