Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
this sounds like a good case for inheritance. –  Mike L. Jan 31 '12 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.. –  500865 Jan 31 '12 at 19:25
sounds more like a case for templates/generics to me –  Ryathal Jan 31 '12 at 19:28
Ryathal: 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 cline Jan 31 '12 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)? –  ysdx Jan 31 '12 at 23:57

5 Answers 5

up vote 6 down vote accepted

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.

share|improve this answer
Same number of objects is right.. But what about the memory allocated for each object? –  500865 Jan 31 '12 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 '12 at 19:48
Does 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. –  Gary Buyn Jan 31 '12 at 20:14
The 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 '12 at 20:15
@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. –  TMN Feb 1 '12 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.

share|improve this answer

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.


share|improve this answer
Can you provide more details and evidence to back up this assertion? –  ChrisF Jan 31 '12 at 20:39
This is not an assertion, it's more of recommendation using Design Patterns. –  Melvin Protacio Jan 31 '12 at 20:58
You still need to provide more details the link you skipped gives more detail. –  ChrisF Jan 31 '12 at 21:01
link discusses the design patterns, the design patterns that could be used will depend on the requirements and perspective of the developer –  Melvin Protacio Jan 31 '12 at 21:11
@MelvinProtacio can you edit your answer to incorporate that explanation? –  user8 Feb 1 '12 at 0:23

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.

share|improve this answer
I 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 '12 at 14:53

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.

share|improve this answer
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. –  DemetriKots Oct 18 '13 at 3:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.