2

Background

I am considering a design that includes a public API class containing many nested private classes. I am doing this for the following reasons:

  1. Why private nesting? They will have no use to any other classes except for by my public API class.
  2. Why classes in the first place? The objects being represented have a significant amount of functionality that they must be their own classes.
  3. Why many classes? The functionality of each of the nested classes is too different from one another to be derived from a single kind of class.

Question

With all of what's being stated above, would this design practice be considered "composition" in the strictest sense of the word?

I would say yes, because I am representing a "part-of" system, where the private classes are part-of the public API class and will never exist outside the lifetime of the API class. That being said, for some reason I think there might be something wrong here. I just want to be sure.

| improve this question | |
  • 1
    Nested private classes? You mean you have a class within a class within a class,... ? That's not good. I personally would go with creating another assembly with one single public class and the rest set to internal. That way you still get the benefit of organization while keeping the output (API) of the dll very simple. – Andy Mar 16 '16 at 14:59
  • @DavidPacker Would that be considered composition? – Snoop Mar 16 '16 at 15:02
  • @StevieV: The Access Modifier applied to a class doesn't affect its ability to compose, at least not within the same DLL (in the case of internal). – Robert Harvey Mar 16 '16 at 15:05
  • 2
    Different assemply = different project, different DLL. By marking a class internal (at least it used to be that way, haven't programmed in C# in some time) you can use a component throughout an entire project (an entire assembly), but another project referencing this project will not see the internal components. You can build fairly complicated but clean-coded code structure with internal classes while not having to expose them to the clients (ie. users) of the project itself. – Andy Mar 16 '16 at 15:54
  • 1
    Just FYI, note that nested classes in Java have an additional feature in that an instance of the nested class (automatically) has access to an instance of the outer class. This is not the case in C#: you would have to create and capture your own reference. – Erik Eidt Mar 16 '16 at 16:20
2

No.

Nested classes only provide one benefit over inheritance: they don't use inheritance. The other benefits of composition, namely polymorphic behavior and code reuse, are absent in nested classes (unless you have an especially large main class, which I would consider a violation of SRP).

That doesn't mean you shouldn't use them. It just means they don't fulfill the spirit of composition.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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