For the better part of this afternoon I was stuck on discovering the appropriate abstractions, whether any of the abstractions were of actual value, and what to name my classes. I had identified a common set of operations, a common sequence of code... Initially I kept mentally pacing back and forth without producing anything of value...
My personal definition of an abstraction: a way to view the problem at a higher level; a common thread or concept in multiple problems; a pattern in the problem space; a class of operations that will follow a similar pattern or "recipe".
I was motivated by the following goals: immediate and future code reuse, decoupling, and cohesion (all of which lead to good -"ilities").
Some problems that arise when trying to achieve this:
1. Where to place the code to maximize the benefit of reuse
2. Where to place the code without breaking good OO principles
3. How to anticipate future needs
4. How to name a class and what its responsible for (basically responsibilities should be evident from the name and the name should make sense when the responsibilities are enumerated)
So finally I was able to wrestle myself out of this and come up with a meaningful and useful abstraction by drawing some quick and dirty diagrams. Now I almost always like text better than diagrams because it usually has more substance. But I've found that diagrams help me to untangle ideas, separate concepts, focus, and organize my thoughts (whereas when I'm writing text its easy for me to jumble up my thoughts, jump from one idea to another without any structure. For example right now I'm writing four different blog topics at the same time, I can't completely focus on one thing, I keep "forking" to use Unix parlance.).
Anyway when I started drawing a simple high level diagram of the major components and how they interact, I was able to more clearly see the responsibilities of each component and what the interactions truly meant. I realized that one of the components at a high level was just a generic "connector" to one our web services and voila an abstraction was born. I was able to identify the boilerplate code and encapsulate it in a well-named abstract class and inherit from this for my specific operations. (BTW I'm purposely avoiding using UML terminology, why bother...)
Why does diagramming work so well? In short by making a diagram "You don't have to keep all of it in your head". If I were to add something to the C2 Wiki, it would be "DontKeepAllOfItInYourHead"... ha.. that makes it look more official!
3 comments:
I agree diagrams are always better than text, as it does not have any boundary of language and grammar. Text sometimes becomes misleading while diagrams always give you clear vision. I think that’s the reason UML is so important as it makes your diagram to standard diagram which cud be understood by anybody. It gives standard platform of describing your diagrams.
I never said diagrams are ALWAYS better than text, in fact I do not believe that at all. Diagrams are good at showing many different concepts at once, at showing relations between pieces, at allowing the viewer to see many things at once. So they are good when you have many ideas in your head and you need to organize them.
However diagrams can never replace text. Text can provide many more specific details, describe in detailed steps what is happening (even more than a sequence diagram), and express concepts that you don't get with lines, circles, arrows, etc.
I agree that diagrams do not have any boundary of language and grammar, but that also allows them to be interpreted in many different ways.
I recommend "Applying UML and Patterns" by Craig Larman. This is a very good, practical textbook on UML 2.0 that emphasizes all aspects of UML, text and diagramming..
ALWAYS does not mean that in all situations, I was talking about current situation. And anyway diagram do require the text description but still they are better than complete text descriptions.
Post a Comment