Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Folks, I have two separate classes. One of them makes http requests/receives response to/from a server and the second one converts received JSON objects into my models (separate classes). I'm thinking it would be an idea to include this class for data converting as an inner class of my first class. Wouldn't my first class be extra big because of it and I need to leave everything as is or this is a good common practice to behave like that?

share|improve this question
Have you considered making the second class package-private? – Oliver Weiler Jan 12 '11 at 20:34
up vote 3 down vote accepted

Inner classes are most commonly used for objects that act directly on the enclosing class. An excellent example of this is iterators. You create a custom implementation of Iterator within your container class, and return an instance of it in your getIterator() or whatever method. This iterator has access to all methods and fields of that container, which may make it easier to implement remove(), for example. Also, that iterator is unique to that class, but it is an implementation of an external, public interface, so it makes sense for it to be hidden as an inner class.

I would apply these questions to your example. If the answer to any of them is no, I'd reccommend making the class stand alone.

  1. Is it unique to your class? That is, can any other class use this converter?
  2. Does it need access to private fields of the enclosing class?
  3. Is it a custom implementation of an existing public interface that should never be accessed in any way but through that interface? If so, there's really no point in making it a public class of it's own. As in the Iterator example, you can return the interface with no hint of the underlying structure. Good encapsulation.

I think your example fails number 2, and probably number 1 too, since it operates on data not specific to the closing class. I don't know about the third; insufficient information. I would not make it an inner class. If you really want to limit access to the class, make it package private (declared with class, not public class)- then it can only be accessed within the package.

share|improve this answer
Thank you very much. – Eugene Jan 12 '11 at 20:08

If it is going to over complicate things without giving you a significant improvement somewhere(execution time, etc) then I don't think it's worth it and would leave it as-is.

share|improve this answer

They seem to be doing two completely unrelated things. So they should be independent classes.

share|improve this answer

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.