Writing JavaScript according to SOLID

Have any one used the SOLID programming principle (or any of it's parts) while developing JavaScript?

I've just started up on reading on it but can't seem to开发者_开发技巧 find anyone that used it for JS. The only part I find easy to implement/use is the "Single responsibility principle".

What I'm looking for is articles or example where these principles are used. And are there any argument's why one shouldn't use some parts?

For example the "Interface segregation principle" says that "the notion that many client specific interfaces are better than one general purpose interface."

But from my knowledge there's no such thing as interfaces in JS (nice if it would be).

It looks like Derek Greer is attempting to take a stab at this with his article series on SOLID JavaScript at Fresh Brewed Code:

1. The Single Responsibility Principle
2. The Open/Closed Principle
3. The Liskov Substitution Principle
4. The Interface Segregation Principle
5. The Dependency Inversion Principle

JavaScript sometimes gets a bad rap as being sub-par to those such as C++, C#, and Java, when in fact it's a very powerful functional programming language that also has object oriented capabilities (although it's not really classified as object oriented)

Perhaps many developers look down on it because so many of them are used to seeing poor programming practices and consequently, buggy behavior in JavaScript. For some unknown reason, it seems more acceptable to be sloppy on the client side. This is something I would like to change.

I believe these SOLID principles are solid. (No pun intended). If you follow these conventions, you will be less likely to accumulate technical debt created by sloppy code, shortcuts, and no architecture. Your code will be more maintainable, more reusable, more modular, less tightly coupled, and scalable and extensible. You'll also be contributing to demonstrating the full power of JavaScript when your product is engineered instead of just recklessly slapped together.

This document describes the fundamentals of SOLID. The same rules apply whether you're referring to C++, Java, JavaScript, or any other object-oriented language.

Code Project - The SOLID Object Oriented Programming Principles

Here is some more information on JavaScript concepts on colourcoding.net.

This accepted answer is flawed. I recommend to read the five articles linked to by Ryan Rensford below. The last article comes to the following conclusion which I failed to communicate (emphasis by me):

While in the course of our examination we saw variations in how the SOLID design principles apply to JavaScript over other languages, each of the principles were shown to have some degree of applicability within JavaScript development.

SOLID is meant for object-oriented programming. JavaScript is a prototype-based language but allows programming in an OOP-manner (if you really try hard to do so). Many people believe that you shouldn't try to force paradigms of languages you learned (like C++/C#/Java) onto others (JavaScript). Here's an article on OOP in JS which also comes to that conclusion.

There are some approaches to OOP in Prototype.js, CoffeeScript, and John Resigs Simple JavaScript Inheritance (each with its own traps).

But the terminology (interfaces, abstraction) of SOLID is difficult to apply to vanilla JavaScript in a proper manner. You will be able to apply "S", and maybe the "L" (which are good concepts). But going further would require constructs like interfaces (which are hard to find in dynamic languages anyway, contracts might work) and the ability to restrict inheritance/modification.

This presentation: SOLID JavaScript In A Wobbly (World Wide Web) by Derick Bailey demonstrates how to use SOLID programming principles while developing javascript.

He explicitly addresses the issue of interfaces in javascript several times. In javascript, interfaces are more of a convention, so it's up to you how to define them. You can write an empty object definition (think of it like an abstract class or an interface). Or you can rely on documentation for your protocols/contracts.

At a more conceptual level, an object's method signatures implicitly define it's interface, so in javascript you can often get by with "duck-typing" and still adhere to SOLID. (!) Here's an example of the "interface segregation principle" from the presentation that demonstrates this:

// Copyright 2014 Muted Solutions, LLC, and freely distributable and re-usable under the MIT License

// JavaScript has no interface construct ...
// sooooooo..... use inheritance instead? o_O

// Rectangle
// ---------

function Rectangle(){}

Rectangle.prototype.area = function(){
  return this.height * this.width;
};

Rectangle.prototype.setHeight = function(height){
  this.height = height;
};

Rectangle.prototype.setWidth = function(width){
  this.width = width;
};

// Square
// ------

function Square(){}

Square.prototype.area = function(){
  return this.size * this.size;
};

Square.prototype.setSize = function(size){
  this.height = size;
  this.width = size;
};

This code and all of the rest of the example code from the talk is posted on GitHub: https://github.com/derickbailey/solid-javascript

Most of SOLID principals depend on abstraction, In other languages such as Java, we can do abstractions by using interfaces, And Javascript doesn't have interfaces, Does that means that we can't achieve SOLID principles in Javascript? The answer is No. This is a great article to clarify the things.

http://www.yusufaytas.com/achieving-abstraction-in-javascript/

In consequence, JavaScript is a weakly typed language and does not have classical support for abstraction. We have tried to achieve abstraction in JavaScript by defining interfaces and using them. Nevertheless, interfaces do not affect our code at all. They are nothing more than a way of documenting code for human beings. All the examples we have shown above would work exactly the same even if we completely remove the interfaces. However, it is about making roles explicit. This increases readability, understandability, and maintainability of the code.

In general, The main goal for SOLID principles is to make the code readable and easy to modify, Applying SOLID to your code is all about trying not to repeat yourself and make your code nicer and cleaner.