Object oriented analysis and real life OOP differences

Question

I usually try to do TDD with not much analysis (no diagrams) before start coding. Usually I find myself spliting a class into other classes to separate concerns. I wonder if a deeper analysis would prevent that. I think that much of OO analysis can't predict some of those cases. What do you think?

Answer 1

I think pre-planning out a lot of your class structure (and all of the different interfaces as well) is extremely important in Object Oriented Design/Programming. You won't find hardly any books out there on the subject that won't first spec out the design using UML and other modeling methods before diving into the code.

Answer 2

For me, the splitting of classes is usually part of a learning process. Either about the problem domain or the process of coding. And usually I do it while coding. Sometimes I bring a co-worker or two to a whiteboard to discuss things.

TDD should let you focus on the problem you're trying to solve. The fact that you're learning about the structure of the problem as you're solving it is an intrinsic part of TDD. Don't go into large up-front analysis/design processes.

Answer 3

"Usually I find myself spliting a class into other classes to separate concerns. I wonder if a deeper analysis would prevent that. I think that much of OO analysis can't predict some of those cases."

I have similar experience in this regard. TDD does help you to design classes better which I do not get in A&D.

However, I have found prior analysis as much helpful. It's like laying out foundations with analysis and then you get detailed design while coding.

Certain things just need to be looked from a bigger perspective.

Answer 4

Most of the time, when I start a programming/design project, I have a good idea not only of what I want it to do at first, but also some of the directions that the requirements are likely to evolve. This drives the choice of initial features (which drives Test Driven Development) and can give me an excuse to split classes in a direction that I think will be useful later.

If you just start choosing test cases randomly from the vast list of features you're considering, then the direction of development of your initial classes will also be somewhat random. So I think part of being an experienced developer is choosing the directions carefully to begin with--not necessarily with a lot of formal analysis, but at least by instinct about what features are going to matter architecturally as the project grows.

One of the main points of XP and TDD is that you don't want to spend too much time on features and directions that aren't called for by your initial requirements, since the customer will change their mind when they see what you've done so far, so you don't want to spend too much time thinking it out. But part of developing your skills and instincts as a developer is exercising and growing your ability to predict which undisclosed may turn out to be important later.

OTOH, the promise of XP and refactoring is that you can fix problems in the initial factorization of the problem when the requirements push you in that direction. I think that's true, but you'll still be a more valuable contributor to the extent that you can make these decisions right the first time. And making it look like luck--"The tests forced me to factor it this way" is part of the skill.