Design Principle
Common
KISS
= Keep it simple stupidDRY
= Don’t Repeat Yourself
SOLID
Single Responsibility Principle
:- A class should have only a single responsibility
Open/closed Principle
- Software entities … should be open for extension, but closed for modification.
Liskov Substitution Principle
: objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.Interface Segregation Principle
- Many client-specific interfaces are better than one general-purpose interface.
- No client should be forced to depend on methods it does not use
Dependency Inversion Principle
- One should depend upon abstractions, [not] concretions.
Ruby On Rails
Convention over Configuration
Fat models, skinny controllers
Zen of Python
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Flat is better than nested.
- Sparse is better than dense.
- Readability counts.
- Special cases aren’t special enough to break the rules.
- Although practicality beats purity.
- Errors should never pass silently.
- Unless explicitly silenced.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one—and preferably only one—obvious way to do it.
- Although that way may not be obvious at first unless you’re Dutch.
- Now is better than never.
- Although never is often better than right now.
- If the implementation is hard to explain, it’s a bad idea.
- If the implementation is easy to explain, it may be a good idea.
- Namespaces are one honking great idea—let’s do more of those!
Unix Philosophy
http://www.faqs.org/docs/artu/ch01s06.html
Unix Philosophy:
- Write programs that do one thing and do it well.
- Write programs to work together.
- Write programs to handle text streams, because that is a universal interface.
Unix rule/principle:
- Write simple parts connected by clean interfaces. (Rule of Modularity)
- Clarity is better than cleverness. (Rule of Clarity)
- Design programs to be connected to other programs. (Rule of Composition)
- Separate policy from mechanism; separate interfaces from engines. (Rule of Separation)
- Design for simplicity; add complexity only where you must. (Rule of Simplicity)
- Write a big program only when it is clear by demonstration that nothing else will do. (Rule of Parsimony)
- Design for visibility to make inspection and debuggingeasier. (Rule of Transparency)
- Robustness is the child of transparency and simplicity.(Rule of Robustness)
- Fold knowledge into data so program logic can be stupid and robust. (Rule of Representation)
- In interface design, always do the least surprising thing. (Rule of Least Surprise)
- When a program has nothing surprising to say, it should say nothing. (Rule of Silence)
- When you must fail, fail noisily and as soon as possible. (Rule of Repair)
- Programmer time is expensive; conserve it in preference to machine time. (Rule of Economy)
- Avoid hand-hacking; write programs to write programs when you can. (Rule of Generation)
- Prototype before polishing. Get it working before you optimize it. (Rule of Optimization)
- Distrust all claims for “one true way”. (Rule of Diversity)
- Design for the future, because it will be here sooner than you think. (Rule of Extensibility)
Rob Pike’s 5 Rules of Programming
- Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.
- Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.
- Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)
- Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.
- Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
Note:
- Pike’s rules 1 and 2 restate Tony Hoare’s famous maxim “Premature optimization is the root of all evil.”
- Ken Thompson rephrased Pike’s rules 3 and 4 as “When in doubt, use brute force.”.
- Rules 3 and 4 are instances of the design philosophy KISS.
- Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month.
- Rule 5 is often shortened to “write stupid code that uses smart objects”.
Rule of Optimization
- Don’t do it!
- Don’t do it, yet (for expert only)
- Profile before optimizing
Domain Driven Development
Reference:
Books:
- The blue book: Domain Driven Design by Eric Evan
- The red book: Implementing Domain-Driven Design by Vaughn Vernon