Object Oriented Design Principles Cheat Sheet — II

List of Some Design Concepts and Principles

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.

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

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.

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

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

Avoid coupling.

A method of an object may only call methods of:
- The object itself.
- An argument of the method.
- Any object created within the method.
- Any direct properties/fields of the object.

Can achieve by using:

  • Factory Pattern
  • 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

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

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.

Adding manpower to a late software project makes it later.

Happy Coding!

--

--

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

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