Principles

Design is a battlefield of multiple acting forces that each drags/push/force the design in a specific way. One some we need to act immediately for some we let them to build pressure and will act later when the decision becomes clearer. Nevertheless is good to understand the stressors.

Design can be learned organically: first learn some fixed forms, after spent entire life getting rid of them.

The fixed forms are principles, philosophies, paradigms, patterns, anti-patterns, idioms, code smells, rules of thumb, adagios, mantras, best practices 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.

The following is a list of principles that are the highest kind of rules that can guide a novice on resolving situations/tendencies of any type of computing entity: code, components, packages, containers, systems.

Intention First

• a style of development where you first clarify the intention: what is given, what you need and only then you focus on how (if is really needed)
• functional is more, is intention only - because implementation is implemented once in the engine and is hidden from sight
  • see SQL
• imperative could be intention first if the method is first defined
  • TDD (Design, Development) also focuses on intention first
• focusing on intention first you have a good chance of getting rid of all accidental complexity
• Corollary:
  • Do not add accidental complexity/data (noise)

SRP - Single Responsibility Principle

• enables composable features

PLS - Principle of Least Surprise

• http://principles-wiki.net/principles:principle_of_least_surprise
• https://en.wikipedia.org/wiki/Principle_of_least_astonishment
• A special form of breaking/violating PLS is puzzlers Please do not write puzzlers and do not fall for the game of understanding them except once when you convert them to proper, explicit behavior. Notorious languages that are breaking PLS:
  • bash - for a sane subset see
    • https://google.github.io/styleguide/shellguide.html
  • perl
  • javascript - for a sane subset see JavaScript: The Good Parts - Douglas Crockford

KISS - Keep It Simple

• http://principles-wiki.net/principles:keep_it_simple_stupid
• Connected concepts: Over Design, YAGNI

YAGNI - You aint gona need it

• YAGNI - https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

DRY - Dont Repeat Yourself

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 everywhere). They should represent intent (not the actual value), meaning there might be multiple constant names for same magical value each of them representing different intention.
  • 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?
  • magical value "EUR". what is a good name for it?

Fail Fast

• http://principles-wiki.net/principles:fail_fast
• https://en.wikipedia.org/wiki/Fail-fast
• https://www.martinfowler.com/ieeeSoftware/failFast.pdf

Tell Don't Ask

• https://martinfowler.com/bliki/TellDontAsk.html

Hollywood Principle - Don't call us We call you

• https://deviq.com/hollywood-principle/

OCP - Open Closed Principle

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

LSP - Liskov Substitution Principle

• http://www.oodesign.com/liskov-s-substitution-principle.html and
• https://dzone.com/articles/the-liskov-substitution-principle-with-examples

DIP - Dependency Inversion Principle / IoC - Inversion of Control

• https://martinfowler.com/bliki/InversionOfControl.html

POE - Premature Optimization is Evil

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

Let it crash

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/

Uniform Access Principle

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
  • kotlin - https://kotlinlang.org/docs/properties.html#backing-fields
  • scala - http://joelabrahamsson.com/learning-scala-part-nine-uniform-access/

Composition over Inheritance

• 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/

Scout Rule

• https://biratkirat.medium.com/step-8-the-boy-scout-rule-robert-c-martin-uncle-bob-9ac839778385

Demeter Law

This "law" is a little more controversial than others. There

• 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
  • https://en.wikipedia.org/wiki/Law_of_Demeter
• CONS
  • https://www.tedinski.com/2018/12/18/the-law-of-demeter.html

CQRS - Command Query (Responsibility) Separation/Segregation

• https://martinfowler.com/bliki/CommandQuerySeparation.html
• https://www.eventstore.com/cqrs-pattern

Rules - future Principles?

• Do not destroy information
• Do not add accidental complexity/data (noise)
• Event sourcing
• Dumb Code Smart Structures
• Null is not an Object
• Array is not an Object
• 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
  • https://www.baeldung.com/cs/program-to-interface
• 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.
• 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.
• Uniform Access Principle

  See also Uniform Access Principle: "uniform access principle The uniform access principle states that variables and parameterless functions should be accessed using the same syntax. Scala supports this principle by not allowing parentheses to be placed at call sites of parameterless functions. As a result, a parameterless function definition can be changed to a val, or vice versa, without affecting client code."

  • https://docs.scala-lang.org/glossary/index.html#uniform-access-principle
  • https://martinfowler.com/bliki/UniformAccessPrinciple.html

Talk with the duck

• https://colterreed.com/talk-to-the-duck/
• https://en.wikipedia.org/wiki/Rubber_duck_debugging
• now the duck could also be
  • your fellow developers on stackoverflow or reddit
  • AI - https://chat.openai.com/chat

Compare

• YAGNI vs KISS
  • https://stackoverflow.com/questions/25999724/whats-the-difference-between-principles-yagni-and-kiss
  • https://enterprisecraftsmanship.com/2015/06/15/kiss-revisited/

Code smells

• magical values

References

• all
  • http://principles-wiki.net/principles:open-closed_principle?s[]=open&s[]=closed
  • http://www.oodesign.com/liskov-s-substitution-principle.html
  • http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign