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?
-
9this sounds like a good case for inheritance.– Mike L.Jan 31, 2012 at 19:17
-
Yes.. That was my initial thought too.. I would like to know how it will affect performance, what problems I could encounter if I keep it the way it is now.. I am working on android app development..– 500865Jan 31, 2012 at 19:25
-
sounds more like a case for templates/generics to me– RyathalJan 31, 2012 at 19:28
-
2Ryathal: Java templates don't actually do anything except produce eliminate the need for some type casts and generate compiler messages. Not sure how you think they would be useful her– kevin clineJan 31, 2012 at 19:32
-
What are the nodes supposed to be/do? Can the type of a node change at runtime (an instance cannot change its class at runtime in Java)?– ysdxJan 31, 2012 at 23:57
Add a comment
|
5 Answers
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.
-
1Same number of objects is right.. But what about the memory allocated for each object?– 500865Jan 31, 2012 at 19:43
-
The class definition will determine how much memory is allocated. You will probably save a little bit of memory with each instantiation using inheritance because each type will only have the fields and methods it needs as well as those provided in the basetype. In you single class model every node type technically has memory allocated for each field and method even if those are never used.– Mike L.Jan 31, 2012 at 19:48
-
1Does that "little bit of memory" actually cause you problems? Have you profiled your code and identified it as a problem? Premature optimization can be bad... it leads to hard to understand code with little or no gain. A design change made with the sole intent of increasing performance is warranted when the current performance is problematic. Removing getters and setters makes your code less flexible. You might get a slight decrease in memory usage but it isn't worth it. Jan 31, 2012 at 20:14
-
5The reason to refactor the design should not be a memory allocation concern. The one class design creates a "blob" class that is trying to act as too many different types. I don't know the exact number of bytes you would save but it wouldn't be significant.– Mike L.Jan 31, 2012 at 20:15
-
1@500865: All methods (including getters and setters) are only stored once, with the class definition. So if you eliminate them, you'll save a handful of bytes, not a handful of bytes per instance. Decreasing code size in Java to save space is rarely useful.– TMNFeb 1, 2012 at 19:40
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.
answered Jan 31, 2012 at 19:40
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.
-
1I don't think a factory pattern is going to help much here. His nodes seems to have different fields depending on the subtype. He is going to want to know the actual subtypes of his nodes. Factory pattern is good when you don't care about the underlying type and rely on polymorphism for the right behavior.– Mike L.Feb 1, 2012 at 14:53
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.
-
Can you provide more details and evidence to back up this assertion?– ChrisF ♦Jan 31, 2012 at 20:39
-
This is not an assertion, it's more of recommendation using Design Patterns. Jan 31, 2012 at 20:58
-
1
-
link discusses the design patterns, the design patterns that could be used will depend on the requirements and perspective of the developer Jan 31, 2012 at 21:11
-
1@MelvinProtacio can you edit your answer to incorporate that explanation?– user8Feb 1, 2012 at 0:23
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.
-
It is not clear what you are getting at. Think about elaborating on your response. What is the right approach if the fields are sparsely populated? You mention a design pattern. Which design pattern, and under what circumstances should it be used? Think about stating some assumptions and providing guidance based on those assumptions. Oct 18, 2013 at 3:23