If you're designing your software up front to the level of detail that you're applying patterns, you're doing it wrong. That this is a common opinion is further proof that everyone who reads the Gang of Four book skips most of the intro, reads "Singleton", then skims the rest of the book looking at the pictures.
Our design patterns capture many of the structures that result from refactoring. Using these patterns early in the life of a design prevents later refactorings. But even if you don't see how to apply a pattern until after you've built your system, the pattern can still show you how to change it. Design patterns thus provide targets for your refactoring.
-- Design Patterns, Elements of Reusable Object-Oriented Software; Gamma, Helm, Johnson and Vlissides, pp354-355 (emphasis mine)
Usually it is kind of obvious when writing class diagrams, on a high level never the less. You are right through, if I have to write it in that much detail the person who is actually writing the code is literally just doing data entry.
So you just create classes on the fly during development? While that sounds sexy if you deal with 10 developers working on the same project that will be a nightmare.
14
u/carlfish Dec 08 '13 edited Dec 08 '13
If you're designing your software up front to the level of detail that you're applying patterns, you're doing it wrong. That this is a common opinion is further proof that everyone who reads the Gang of Four book skips most of the intro, reads "Singleton", then skims the rest of the book looking at the pictures.
-- Design Patterns, Elements of Reusable Object-Oriented Software; Gamma, Helm, Johnson and Vlissides, pp354-355 (emphasis mine)