Refactorable God v.s. too many classe

Question

So I have this problem: in order to structure my code hierarchically, for every new tiny thing, I create a separate sub-folder, file, class ... and in it one 10-line function. It is an anti-pattern.

Lately I have been trying to err on the opposite side. That is, when I need something new, instead of dreaming up grand hierarchies, I just type the code somewhere inside the existing classes.

This is beginning to look like another anti-pattern, and I wander which is the lesser evil.

So the pattern is the following: write everything here and now, and, when the need arises, refactor the code out to a separate class. Kind of refactorable God.

Am I using this as an excuse to write God classes? Or is there a pattern/worklfow, similar to this one, that I can adopt? What are the indicators that things are going well/terrible?

possible duplicate of [How do I prove or disprove “god” objects are wrong?](http://programmers.stackexchange.com/q/178317/31260) See also: [Keep my classes and methods as small as possible?](http://programmers.stackexchange.com/questions/125357/keep-my-classes-and-methods-as-small-as-possible) and [Too complex/too many objects?](http://programmers.stackexchange.com/questions/176780/too-complex-too-many-objects) — gnat, Sep 16 '13 at 13:16
Why would you need to create a separate sub-folder for each new class? — Bobson, Sep 16 '13 at 13:44
@Bobson, well, who knows, maybe in time the class expands so much as to become a family of files with multitudes of classes. I am exagarating a little, but the point is I'm over-engineering. — Vorac, Sep 16 '13 at 13:59
Search for the [Tao](http://www.canonical.org/~kragen/tao-of-programming.html) and one day you will be able to follow it ;) — back2dos, Sep 16 '13 at 14:17
What I tend to do is write into a class until it begins to look cluttered, then look for multiple uses for that class and I split it as best I can. "Coding by mitosis" is the best I can describe it. Sounds like it would create a mess, but all my classes have single-purpose uses (or it would have been split). For someone who thinks in detail first, then the bigger picture, this works nicely. — Neil, Sep 16 '13 at 15:13

score 1 · Answer 1 · answered Sep 16 '13 at 09:46

1

When creating a new method, first think:

Does this method correspond to a property or a behavior of an object, or:
Is it something completely new?

In the first case, you'll rather put it in the corresponding class. In the second case, indeed, you'll create a new class.

The problem with the first case is that sometimes, you'll end up with a class too big. This is a hint that the class should be refactored into multiple smaller classes. What is big or not depends on the circumstances. For example:

Rectangle
{
    int x;
    int y;
    int width;
    int height;
}

can easily be refactored into:

Rectangle
{
    Point position;
    Size size;
}

Point
{
    int x;
    int y;
}

Size
{
    int width;
    int height;
}

answered Sep 16 '13 at 09:46

Arseni Mourzenko

134,780
31
343
513

3

It appears to me that you are just restating the problem. However, this is probably because I did not provide adequate concrete information in the question. **How do I know when am I passing the point of "easily refactorable big class" and going into "spageti code" land?** – Vorac Sep 16 '13 at 09:57
2

You know that by looking at the architecture and design of the code. If your classes are adequate, i.e. it's obvious for a reader that a specific method will be in a specific class, and indeed, it is there, then you followed proper OOP. If nobody, not even you in six months, knows where is the specific method, then a bit (or a lot) of refactoring may be a good idea. – Arseni Mourzenko Sep 16 '13 at 10:03
I don't see the value in the refactoring. – Sklivvz Sep 16 '13 at 15:46

score 1 · Accepted Answer · answered Sep 16 '13 at 13:08

I don't remember the chapter, but the author of the working with legacy code but I think the book suggest the following workflow :

make sure you have tests. If you can't test your code without modifying it, only perform the most basic/easy modifications needed.
code a test for the new functionality
code the functionality directly where you want the work to happen and make the test pass
refactor to remove duplication and make the code SOLID compliant.

Even without test, I tend to follow a similar pattern: first get the thing to work in the simplest and easiest way, then immediately refactor until you are satisfied with the code organization. If you wait, you (or your colleague) will pay a higher price of trying to understand messy code.

The fact that you first solve the problem in the most simple and straightforward way helps you to avoid over-engineering the solution. Focusing first on correctness then on readability/architecture really helps you to be productive.

Refactorable God v.s. too many classe

2 Answers2