Hi all,<p>When I start developing my applications mostly I prefer to start with MVC pattern.<p>I have difficulty in deciding when to choose a different pattern and which one. The books that I have read mostly describes how the pattern works. But I couldn't find resource that can help me decide in which scenario I should change my pattern.<p>Can someone please help me point me in the right direction?<p>Thanks.
The original idea for documenting design patterns goes something like this:<p>> 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.<p>-- <a href="https://en.m.wikipedia.org/wiki/Design_pattern" rel="nofollow">https://en.m.wikipedia.org/wiki/Design_pattern</a><p>Some key parts of documenting a pattern are:<p>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<p>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.<p>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.<p>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!