Object Oriented Design Principles Cheat Sheet — II

Photo by Autumn Studio on Unsplash

TL;DR

This is my second post about design patterns and principles. Like I mentioned in my previous post, my aim here is not to go into detail but create a cheatsheet to quickly review before interviews to serve as a reminder.

KISS (Keep It Simple, Stupid)

Keep it simple, avoid complexities => clear to understand, easy to debug, easy to maintain

DRY (Don’t Repeat Yourself) — DIE (Duplication is Evil)

Avoid duplication — Consider modularizing functionality that you use more than once
- If you have a repeated piece of code, move inside a new function
- If you have a function that you’ve defined in several places, then move it into a common module.
- If the same applies to your module, consider turning it into a common library.

YAGNI (You Aren’t Gonna Need It)

Avoid over-engineering (code bloat), implement only necessary requirements.

Curly’s Law — Do One Thing

A entity (class, function, variable) should mean one thing, and one thing only.

Law of Demeter — Don’t talk to strangers

Avoid coupling.

Inversion of Control — Hollywood Principle, “Don’t call us, we’ll call you”

Can achieve by using:

  • Service Locator Pattern: Instead of instantiating dependent class itself, it gets an implementation from the service locator.
    Some argue that it is an anti-pattern which obscures dependencies and makes software harder to test.
  • Dependency Injection:
    To understand Dependency Injection, firstly I should give some details about IoC (Inversion of Control):
    Inversion of Control — is to provide any kind of callback, instead of acting ourself directly. It enables the creation of dependent objects to be inverted. It helps designing testable, maintainable and extensible loosely coupled classes.
    Using IoC, you are not new’ing up your objects. IoC containers (DI frameworks) will do that and manage the lifetime of them.
    Dependency Injection — is a more specific version of IoC pattern, where implementations are passed into an object through constructors/setters/service lookups, which the object will ‘depend’ on in order to behave correctly.
  • Template Method Pattern
    It is kind of IoC without using DI.
  • Strategy Pattern

Boy-Scout Rule

Refactoring (Uncle Bob) — always leave the code behind in a better state than you found it to avoid technical debt

Linus’s Law

Given enough eyeballs, all bugs are shallow. — recommends software reviewing process where multiple developers inspect the piece of code before it’s accepted and merged.

Brooks’s Law

Adding manpower to a late software project makes it later.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nil Seri

Nil Seri

I would love to change the world, but they won’t give me the source code | coding 👩🏼‍💻 | coffee ☕️ | jazz 🎷 | anime 🐲 | books 📚 | drawing 🎨