Principles
There are principles, philosophies, paradigms, rules of thumb, adagios, mantras, best practices, patterns, anti-patterns, idioms, code smells etc. Some of them applies to the way things are (items and the relationship between them), some of them talk about a process or thinking process (how to move from one state to other). The first are called design principles, the later process principles.
- Dumb Code Smart Structures
- Null is not an Object
- Array is not an Object
- enables composable features
- http://principles-wiki.net/principles:principle_of_least_surprise
- https://en.wikipedia.org/wiki/Principle_of_least_astonishment
- http://principles-wiki.net/principles:keep_it_simple_stupid
- Connected concepts: Over Design, YAGNI
Fix bugs in one place, future reuse and improvements done in one place.
- http://principles-wiki.net/principles:don_t_repeat_yourself
- remove magical values (use constants that you can use everywhre)
- magical value 1. what is a good name for it?
- magical value 0. what is a good name for it?
- magical value 400. what is a good name for it?
- http://principles-wiki.net/principles:fail_fast
- https://en.wikipedia.org/wiki/Fail-fast
- https://www.martinfowler.com/ieeeSoftware/failFast.pdf
A part(component, class, api, schema, server) should be Open for extension, Closed for modification
- https://en.wikipedia.org/wiki/Open/closed_principle
- http://principles-wiki.net/principles:open-closed_principle?s[]=open&s[]=closed
- original paper by Uncle Bob - https://www.cs.duke.edu/courses/fall07/cps108/papers/ocp.pdf
- http://www.oodesign.com/liskov-s-substitution-principle.html and
- https://dzone.com/articles/the-liskov-substitution-principle-with-examples
Premature Optimization is the Root of all Evil Optimization is done after a bug is filled with proof that the new code is improving the situation. Use a profiler Connected with YAGNI. Michael A. Jackson
- The First Rule of Program Optimization: Don't do it.
- The Second Rule of Program Optimization – For experts only: Don't do it yet.
See also Intro-to-Performance
On software systems in worst case scenario the systems should be able to crash/reboot and continue from where they left.
- http://web.archive.org/web/20090430014122/http://nplus1.org/articles/a-crash-course-in-failure/
- https://www.zuehlke.com/blog/en/is-it-safe-to-let-it-crash/
The uniform access principle of computer programming was put forth by Bertrand Meyer (originally in Object-Oriented Software Construction). It states "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation".
- https://martinfowler.com/bliki/UniformAccessPrinciple.html
- https://www.quora.com/Why-are-getters-and-setters-increasingly-considered-an-anti-pattern-in-programming-circles
- https://en.wikipedia.org/wiki/Uniform_access_principle
- Implementation
- other names: composite reuse principle
- articles
-
https://en.wikipedia.org/wiki/Composition_over_inheritance
To favor composition over inheritance is a design principle that gives the design higher flexibility. It is more natural to build business-domain classes out of various components than trying to find commonality between them and creating a family tree Composition relation is more flexible as it may be changed on runtime, while sub-typing relations are static and need recompilation in many languages. Some languages, notably Go,and Rust use type composition exclusively.[4] see also composition helpers for each language
- https://refactoring.guru/replace-inheritance-with-delegation
- https://www.matsim.org/docs/devguide/prefer-composition-and-delegation-over-inheritance
- https://www.geeksforgeeks.org/delegation-vs-inheritance-java/
-
https://en.wikipedia.org/wiki/Composition_over_inheritance
- Infinite Funds Syndrome (Cost of perfection might be an order of magnitude higher than good enough solution) - The assumption of an engineer that have infinite time & funds to do a perfect software(NASA, Nuclear, Aviation) when a good enough (at a fraction of the costs) will do just fine. Usually engineers that do not keep OCD under control.
- Solution: focus on effort and impact (ROI - Return Of Investment) = Value Gained Or Impact / Effort Quantified in Both Resources and Time to have Perfect Solution (read The Nature of Software Development)
- Maximum Impact is limited, Value is effort or negative costs and includes technical debt, lost opportunities and comes from all stakeholders
- Effort could be infinite
- Programming to Interfaces
- NIHS - Not Invented Here Syndrome
- DCSS - Dumb code, smart structures
- FailFast
- Elegant Objects
- Defer Execution - do not compute what is not needed. See functional style.
- Do not destroy information
- No Code > Good Code > Incomplete Code > Wrong Code (good information > incomplete information > wrong information)
- Conservative code (open close principle) Do write code to fix your problem/test and only your problem/test. All the other cases should be "fixed" only if they suffer from that bug.
- Demeter Law
- Parallel: E suficient sa se inteleaga ce inseamna Law of Demeter si impactul asupra designului. Exista forte care complica designul. Exista forte care il simplifica. Daca suntem constienti putem lua decizii mai bune. O paralela ar fi un sistem in care ai masina, jenti, cauciuc, vintil si aer/azot. Daca doar ca sa schimbi din aer in azot trebuie sa schimbi masina sau jentile … ai cam incalcat law of demeter.
- PRO
- CONS
- YAGNI vs KISS
- magical values