HACKER Q&A
📣 gkrishna

When to decide to evolve my design pattern?


Hi all,

When I start developing my applications mostly I prefer to start with MVC pattern.

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.

Can someone please help me point me in the right direction?

Thanks.

  👤 shoo Accepted Answer ✓
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!