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.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by gnat, Kilian Foth, GlenH7, Dan Pichelman, Robert Harvey Sep 18 '13 at 23:39

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
    
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
1  
Search for the Tao 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

2 Answers 2

up vote 1 down vote accepted

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

  1. make sure you have tests. If you can't test your code without modifying it, only perform the most basic/easy modifications needed.

  2. code a test for the new functionality

  3. code the functionality directly where you want the work to happen and make the test pass

  4. 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.

share|improve this answer

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;
}
share|improve this answer
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 9: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. –  MainMa Sep 16 '13 at 10:03
    
I don't see the value in the refactoring. –  Ebenezer Sklivvze Sep 16 '13 at 15:46

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