I currently have a Java class called "node" which has a number of fields. Which fields in the class are used depends on a field called "type". There are close to 10 (this can grow) different types of "nodes". I was wondering if it is good to have a single class to handle all types or have different class for each type. What is the best programming practice in these cases? I would like to know (or a link to similar question/tutorials) how the performance will be affected (like memory etc.) if I use a single class?
This is a standard case for inheritance. You do not incur performance problems due to sub-classing. If you are performing any casting between sub types and super types several if statements will be executed at run time and are used to check for cast exceptions. In your single class model you would need to check your "type" field whenever a method or field is accessed to see if that particular "type" of node has those fields available. Memory should also not be a concern because you will be creating the same number of objects in either the single class model or the inheritance model.
The giveaway is in the name of your variable:
type. You are trying to represent a type using a variable when that is exactly what classes are for. In your case I would consider refactoring to Replace Type Code with Subclasses.
Each subclass should contain the fields relevant only to it. By doing this refactoring, your code will be easier to maintain and extend.
Good design generally trumps (and usually helps) performance. In this case - don't worry about it.
This situation is the perfect case for applying the factory pattern which basically creates the required subclass based on specific inputs. Also inheritance is not to be abused as changes to the super class trickle down to sub-classes.
It might be a decorator or state design pattern or a composition
since we are talking about nodes here, composite pattern is a good candidate and since every node might possibly behave differently depending on the type, we may consider each node instance as states with different handling of a more generic behavior or we could have a base abstract class for a node and several concrete classes that are just decorators to provide additional functionality or customized behaviors.
I'd say that you can use a design pattern, subclassing or even a single class. It depends on the sparsity of the fields.
Are most of the fields or only a few ones in a single class null?
Are there a lot of different "types" involved?
Those are questions to be answered before a decision can be made.
protected by gnat Mar 11 '17 at 21:13
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?