Skip to content

MaxWenzel/laws-rules-principles

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 

Repository files navigation

Laws, Rules & Principles

The Priciples of Object Oriented Desgin

Class Design

  • The Single Responsibility Principle: A class should have one, and only one, reason to change.

  • The Open Closed Principle: You should be able to extend a classes behavior, without modifying it.

  • The Liskov Substitution Principle: Derived classes must be substitutable for their base classes.

  • The Interface Segregation Principle: Make fine grained interfaces that are client specific.

  • The Dependency Inversion Principle: Depend on abstractions, not on concretions.

Package Design

Cohesion

  • The Release Reuse Equivalency Principle: The granule of reuse is the granule of release.

  • The Common Closure Principle: Classes that change together are packaged together.

  • The Common Reuse Principle: Classes that are used together are packaged together.

Coupling

  • The Acyclic Dependencies Principle: The dependency graph of packages must have no cycles.

  • The Stable Dependencies Principle: Depend in the direction of stability.

  • The Stable Abstractions Principle: Abstractness increases with stability.

Robustness Principle

In computing, the robustness principle is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as Postel’s law, after Jon Postel, who used the wording in an early specification of TCP.

Brooks' law

Adding manpower to a late software project makes it later.

Law of Holes

The first law of holes, or the law of holes, is an adage which states: "if you find yourself in a hole, stop digging". Digging a hole makes it deeper and therefore harder to get out of, which is used as a metaphor that when in an untenable position, it is best to stop carrying on and exacerbating the situation.

Law of Demeter

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was proposed by Ian Holland at Northeastern University towards the end of 1987,[1] and can be succinctly summarized in each of the following ways:

  • Each unit should have only limited knowledge about other units: only units "closely" related to the current unit.

  • Each unit should only talk to its friends; don’t talk to strangers.

  • Only talk to your immediate friends.

Conway’s Law

Any piece of software reflects the organizational structure that produced it.

Or even more clearly:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Moore’s Law

The power of computers per unit cost doubles every 24 month.

The most popular version states:

The number of transistors on an integrated circuit will double in about 18 months.

Or

The processing speed of computers will double every two years!

Wirth’s law

Software gets slower faster than hardware gets faster.

Gall’s law

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Pareto Principle aka The 80-20 rule

For many phenomena, 80% of consequences stem from 20% of the causes.

This is the principle behind the painful truth that 80% of the bugs in the code arise from 20% of the code. Otherwise stated, 80% of the work done in a company is performed by 20% of the staff. The problem is you don’t always have a clear idea of which 20%.

Abbreviations

ACID

ACID is an acronym that stands for Atomicity, Consistency, Isolation, Durability. These are explained below.

Atomicity

Atomicity means that you guarantee that either all of the transaction succeeds or none of it does. You don’t get part of it succeeding and part of it not. If one part of the transaction fails, the whole transaction fails. With atomicity, it’s either “all or nothing”.

Consistency

This ensures that you guarantee that all data will be consistent. All data will be valid according to all defined rules, including any constraints, cascades, and triggers that have been applied on the database.

Isolation

Guarantees that all transactions will occur in isolation. No transaction will be affected by any other transaction. So a transaction cannot read data from any other transaction that has not yet completed.

BASE

  • Basic Availability: The database appears to work most of the time.

  • Soft-state: Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.

  • Eventual consistency: Stores exhibit consistency at some later point (e.g., lazily at read time).

CAP theorem

  • Consistency: Every read receives the most recent write or an error

  • Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write

  • Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

DRY principle

Don’t repeat yourself (DRY, or sometimes do not repeat yourself) is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.

HATEOAS

Hypermedia as the Engine of Application State (HATEOAS) is a constraint of the REST application architecture that distinguishes it from other network application architectures.

With HATEOAS, a client interacts with a network application whose application servers provide information dynamically through hypermedia. A REST client needs little to no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.

KISS principle

KISS, an acronym for keep it simple, stupid, is a design principle noted by the U.S. Navy in 1960.The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. The phrase has been associated with aircraft engineer Kelly Johnson. The term "KISS principle" was in popular use by 1970. Variations on the phrase include: "Keep it simple, silly", "keep it short and simple", "keep it simple and straightforward", "keep it small and simple", "keep it simple, soldier", or "keep it simple, sailor".

REST

Representational state transfer (REST) is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. REST defines a set of constraints for how the architecture of an Internet-scale distributed hypermedia system, such as the Web, should behave. The REST architectural style emphasises the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching components to reduce user-perceived latency, enforce security, and encapsulate legacy systems.[1] REST has been employed throughout the software industry and is a widely accepted set of guidelines for creating stateless, reliable web services.

WISCY

Why Isn’t Someone Coding Yet (WISCY)?

WYSIWYG

In computing, WYSIWYG, an acronym for What You See Is What You Get,is a system in which editing software allows content to be edited in a form that resembles its appearance when printed or displayed as a finished product, such as a printed document, web page, or slide presentation.

YAGNI principle

"You aren’t gonna need it" (YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them." Other forms of the phrase include "You aren’t going to need it" and "You ain’t gonna need it".

About

Laws, rules and principles for Development

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published