Is having empty children classes, just to specify, a bad practice?Lets suppose I've a generic Product class. There are electrical, electronic and mechanical products. I need to represent all them and must be able to differ each one in some operations.I've two options:add a member named type in Product class to specify whether it's a electrical, electronic or mechanical product.create children classes of Product, one for each kind of product: ElectricalProduct, ElectronicProduct and MechanicalProduct. As these classes don't differ from each other in methods or members - already defined in parent class - they would be all empty.I consider second option a better approach, but is it the right way? I've never seen such thing on any application or library.What do you thing? Any suggestion?Edit:Here is an example of doing it using second option: https://gist.github.com/tsouzar/c2ffebbcdad30920bf06I can't see a better way of doing it, but I don't know if it is a good practice to have that empty classes.
Specific empty children classes
object oriented design
Now that you've explained more fully, it seems that there really is no subclass-specific logic.  In that case, inheritance is not the right choice.  If there really are only minor ways in which other parts of the code treat products, putting code into product classes would be wrong - a violation of separation of concerns which would encumber the product classes with knowledge of other parts of your system.  The sorting example makes that clear. Products should not know how they are sorted or stored or presented; if the code which sorts or presents objects is changed, the product class should not need to be rewritten.I apologise for doubting you on that.  We see so many people here presenting questions which are based on poor OO knowledge and I assumed this was the case when I should have asked for more info first.In fact...The method overloading choice, as shown in your example code, is actually going against principles like the separation of concerns and DRY.  What is the common thing about the  add_product method?  It adds a product to the appropriate collection.  But in the example code, that single, fundamentally identical task is duplicated in three different places.  This is really scarcely different to a chain of if..then..else logic.The logic is duplicated and any changes to the common behaviour will have to be duplicated in each place.  Mistakes are likely and will go undetected.The product-adding code should not need to know what types of products are available.  All it needs to know is that there are a variety of products, each of which should be added to an appropriate collection.  Making it aware means you have to change this section of the code every time you add a new product.A better way to do this, if you really do need a separate collection for each type of product, would be to have a map of product collections.  The key would be the product type.  Then you could have one single product_add method, which consults that map and adds the product to the right place.  Even if you discovered that there is some need for different product subclasses, this method doesn't need to know.  The object class itself could be the key to the map, for example.Since more than one method is likely to want to update or read from those collections, it is probably better to have a Products object which stores the objects.  Whether it contains a map of N different collections or one collection which it knows how to filter/search by type is an implementation detail which need not concern other parts of your code.In SummarySince there really seems to be no product-specific code, extra empty classes are not only useless, they complicated your code and make it more fragile.  A 'type' member is better.Most of your code doesn't even need to know that there is such a member.In each domain (the clearly separate sections of your application), identify those few bits which genuinely need to differentiate between product types.Isolate them in special helper classes or functions which will return the appropriate product (or do the appropriate thing which matches the type)Maps are very useful (they can contain not only collections but other helper objects/functions to hand back to some other code to do the appropriate thing with this object) but should be hidden from anything but the privileged code which really needs to be product-type aware.If you do that, not only will your code be cleaner and more elegant (free from ugly if..then..else chains, for one thing), if you ever do find a real need for product subclasses, almost none of your existing code will have to change.  And even they need only change their internal implementation, because their code will still be no concern of the product class or any of its subclasses.There is still plenty of fun to be had with adding new classes in the respective domains to encapsulate any I know what kind of products there are.  One challenge is differentiating between the bits of those code which are domain specific (e.g. sorting in a collection which is only relevant in one domain) from those which are actually general.  The list of all valid product types, for example, should be an enum which can be fetched by any product-aware domain-specific code.  Any map should use that enum as the type for its key.  Any function which takes a product type as a parameter should take a parameter only of that enum type and so on. Now, where in your code are you going to define that enum?