I currently have an object that is composed from several simple objects. Each simple object is used to render a particular portion of the larger object as a whole. Think of it as building a 3D structure such as a house for rendering to the screen:

  • House
    • Walls
    • Roof
    • Windows
    • Doors

Now, in most cases, we can just render a model and the work is done, but in this case I am essentially building the model from scratch. Each piece can be built using more simplistic objects already present such as Mesh. This however requires constructing the vertices and indices of each fundamental piece of the house.

The way the current code is set up I currently build each part of the house within the House class which prevents reusability (which isn't really too big of a concern here), and definitely makes the House class very hard to understand and maintain without spending half the day analyzing it. As a basic example:

public class House : RenderObject {
    private Mesh[] walls;
    private Mesh[] roof;
    private Mesh[] windows;
    private Mesh[] doors;

    public void Initialize() {
        // Build walls.
        // Build roof.
        // Build windows.
        // Build doors.

My first thought is that the initialize method can be refactored into separate methods to handle building each piece; but, this conflicts with the thought that occurs simultaneously.

Should each piece of the House object be its own class?

  • This would improve:
    • Maintainability
    • Readability
    • Reusability

My concern is that perhaps moving each piece to its own class wouldn't really be worth the effort if it is never really reused, but then I begin arguing with myself along the lines of perhaps it could be, this is a public API after all.

  • 2
    Please rephrase your question's subject line. It's cute but irrelevant here.
    – nadir
    Jan 23, 2019 at 9:36
  • This sounds like a classic case of YAGNI. As for "hard to understand..." I think your problem could be solved by documenting the class well with comments and meaningful property naming instead of trying to reorganize something with extra classes that won't even be reused. Jan 23, 2019 at 19:49

1 Answer 1


What is the public API exactly ? From reading your question the user interacts with the House class only.

Using OOP approach as you ask here can(/may) help you improve the three aspects you mentioned in the question, but do you find yourself struggling with problems of maintenance or reusability in your system (as a whole) ? (as you phrase it the answer is no)

Your true problem is the House unit, working with the low-level class Mesh and from it extract higher level entities such as Wall, Roof etc. made your House class unreadable and so hard to maintain.

If you find that the House unit is a crucial entity in your system, and you/other programmers in your team maintain it regularly you should (even must) put the effort into refactoring it and make it maintainable.

This can be achieved by creating classes to this entities (Wall, Roof etc.) that will interact with the Mesh class accordingly and make the House class interact solely with their public API (without the Mesh class). You may even find opportunities to reuse between them.
Moreover, since you indicated a high cohesion between this entities and the House class, it may be advisable to make each of them an inner-class of the House class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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