BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

SOLID Design Principles for JavaScript

| by Jan Stenberg Follow 6 Followers on Jan 22, 2014. Estimated reading time: 1 minute |

Many developers have worked in object oriented languages and many are working in JavaScript but very few use object orientation principles together with JavaScript, Derick Bailey, an author and developer focusing on JavaScript, stated in a recent presentation at CodeMash. In object oriented programming we talk about foundations and principles as a base for our work but when moving from class based static languages to loosely typed, not class based languages, we often find it hard to apply the same principles.
Derick claims there are a lot of good principles, practices and patterns available in order to help developers writing good stable JavaScript code, one example being the SOLID principles, identified by Robert C. Martin, in the early 2000s.
Derick describes the SOLID principles as five individual patterns that play well together and walks through all five using code samples and looking at some idiosyncrasies in JavaScript that makes applying these principles a little bit different compared to when using them in languages like Java and C#.
Derick’s definition of the five principles are:

  • Single Responsibility Principle. Everything should have only one reason to change. This will help developers understand the context and responsibility of what they are building and when there is a need for change.
  • Open-Closed Principle. A change in behaviour should be possible without changing existing code, e.g. by using extension points and creating code that can be plugged in.
  • Liskov Substitution Principle. Derived objects or types must be substitutable for their base. For Derick this is a more focused version of the Open-Closed principle.
  • Interface Segregation Principle. A client should not be forced to depend on interfaces it doesn’t use. A problem is that there are no explicit interfaces in JS, but there are ways around this.
  • Dependency Inversion Principle. Consists of two concepts, abstraction which states that we should depend on abstractions, not on concrete implementations and ownership that states that low level implementation should depend on high level concepts.

Derick ends with stating that if you have large monolithic chunks of code in your system, SOLID will help you break these into individual pieces. It will not decrease complexity, but will help you create abstractions and group details into larger concepts that we can reason about.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT