| The original idea for documenting design patterns goes something like this: > Documenting a pattern requires explaining why a particular situation causes problems, and how the components of the pattern relate to each other to give the solution.[3] Christopher Alexander describes common design problems as arising from "conflicting forces"—such as the conflict between wanting a room to be sunny and wanting it not to overheat on summer afternoons. A pattern would not tell the designer how many windows to put in the room; instead, it would propose a set of values to guide the designer toward a decision that is best for their particular application.
> Pattern documentation should also explain when it is applicable. -- https://en.m.wikipedia.org/wiki/Design_pattern Some key parts of documenting a pattern are: Describing the context, the situation in which a problem arises; clearly describing which problem is to be solved; describing a solution to the problem (ideally compared against alternatives); and discussing in what situations a proposed solution would or would not be applicable If a book is only talking about how to implement some pattern rather than when it might make sense to use it, or how to derive the pattern from the constraints of a problem, that book won't really help you do design. You could learn more about how to write an engineering design document that describes a context, states a problem and a clear goal to be solved, explores some alternative solutions and then recommends a particular solution. Rule of thumb: solve the problem you actually have, not the problem you want to have. If there isn't a problem causing you a lot of pain, don't change anything. If there is a problem causing you a lot of pain, start brainstorming what changes you could make that might reduce the pain! |