2011-01-17 11 views
31

¿Alguien ha usado el principio de programación SOLIDO (o cualquiera de sus partes) mientras desarrolla JavaScript?Escribir JavaScript según SOLID

Acabo de empezar a leer, pero parece que no puedo encontrar a nadie que lo haya usado para JS. La única parte que encuentro fácil de implementar/usar es el "principio de responsabilidad única".

Lo que estoy buscando son artículos o ejemplos donde se usan estos principios. ¿Y hay algún argumento de por qué uno no debería usar algunas partes?

Por ejemplo, el "principio de segregación de la interfaz" dice que "la noción de que muchas interfaces específicas del cliente son mejores que una interfaz de propósito general".

Pero, por lo que sé, no existen las interfaces en JS (bueno, si lo fuera).

+0

Puede usar http: // inversify.io/ –

Respuesta

47

Parece que Derek Greer está tratando de tomar una puñalada en esto con su serie de artículos de JavaScript sólido a Fresh Código elaborado cerveza:

  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
+0

¡Buen enlace! Derek describe bien los principios allí. – PhilT

+0

enlaces está roto :( –

+2

@StevenKoch He actualizado los enlaces Parece que Derek Greer ha movido blogs y el DNS de la anterior finalmente se fue. –

12

JavaScript a veces tiene mala reputación por ser inferior a C++, C# y Java, cuando de hecho es un lenguaje de programación funcional muy poderoso que también tiene capacidades orientadas a objetos (aunque en realidad no está clasificado como objeto) orientado)

Tal vez muchos desarrolladores lo desprecian porque muchos de ellos están acostumbrados a ver prácticas de programación deficientes y, en consecuencia, el comportamiento de errores en JavaScript. Por alguna razón desconocida, parece más aceptable ser descuidado en el lado del cliente. Esto es algo que me gustaría cambiar.

Creo que estos principios SÓLIDOS son sólidos. (Sin juego de palabras) Si sigue estas convenciones, es menos probable que acumule deuda técnica creada por código descuidado, accesos directos y sin arquitectura. Su código será más fácil de mantener, más reutilizable, más modular, menos acoplado y escalable y extensible. También contribuirá a demostrar todo el poder de JavaScript cuando se diseñe su producto en lugar de simplemente abofetearse.

Este documento describe los fundamentos de SOLID. Las mismas reglas se aplican tanto si se refiere a C++, Java, JavaScript o cualquier otro lenguaje orientado a objetos.

http://www.codeproject.com/Articles/60845/The-S-O-L-I-D-Object-Oriented-Programming-OOP-Prin.aspx

Aquí hay más información sobre los conceptos de JavaScript: http://www.colourcoding.net/blog/Tags/SOLID%20Principles/default.aspx

+0

Si pudiera +100, lo haría. –

4

Esta respuesta aceptada es errónea. Recomiendo leer los cinco artículos vinculados por Ryan Rensford a continuación. El last article llega a la siguiente conclusión a la que no pude comunicar (el subrayado por mí):

Mientras que en el curso de nuestro examen vimos variaciones en cómo los principios diseño sólido se aplican a JavaScript sobre otras lenguas, cada una de las Los principios se mostraron para tener algún grado de aplicabilidad dentro del desarrollo de JavaScript.

SOLID está destinado a la programación orientada a objetos. JavaScript es un lenguaje basado en prototipos, pero permite la programación de manera OOP (si realmente se esfuerza por hacerlo). Muchas personas creen que no debes intentar forzar paradigmas de idiomas que aprendiste (como C++/C#/Java) en otros (JavaScript). Aquí hay un artículo en OOP in JS que también llega a esa conclusión.

Hay algunos enfoques de programación orientada a objetos en Prototype.js, CoffeeScript, y John Resigs Simple JavaScript Inheritance (cada uno con sus propias trampas).

Pero la terminología (interfaces, abstracción) de SOLID es difícil de aplicar a JavaScript vainilla de manera adecuada. Podrás aplicar "S", y tal vez la "L" (que son buenos conceptos). Pero ir más allá requeriría construcciones como interfaces (que son difíciles de encontrar en los lenguajes dinámicos de todos modos, los contratos podrían funcionar) y la capacidad de restringir la herencia/modificación.

+6

No estoy de acuerdo con que esto sea un consenso común. Muchas bibliotecas de JavaScript usan estas técnicas para mantener la encapsulación, admitir espacios de nombres y evitar colisiones. Acepto que las reglas de OO en JavaScript no deben ser las mismas que en C++/C#/Java, ya que hay ciertas cosas que son realmente difíciles de aplicar (métodos/campos privados). Sin embargo, es necesario que haya algunas reglas para mantener el código limpio, sin colisiones y reutilizable. Entonces, si alguien quiere adoptar algunos principios de SOLID, no veo el daño al hacerlo. – jmort253

+0

Estoy de acuerdo en que no debería haber usado "común", especialmente porque hay muchos enfoques de OOP en JS (editado mi respuesta). –

+6

@Marcel, creo que estás mezclando la implementación con el diseño. Los principios SÓLIDOS son solo eso (principios/ideas). Hay ejemplos de cómo puede implementar los principios en determinados idiomas (el artículo de Robert Martin menciona específicamente a C++, por ejemplo), pero las ideas son independientes del idioma y muy sólidas para la creación de software que se pueda mantener. Creo que un lenguaje dinámico como Javascript puede beneficiar aún más a esas ideas, ya que las cosas en Javascript (y muchos lenguajes dinámicos) pueden volverse difíciles de manejar si no se diseñan cuidadosamente. –

2

Esta presentación: SOLID JavaScript In A Wobbly (World Wide Web) de Derick Bailey demuestra cómo utilizar principios de programación SÓLIDOS durante el desarrollo de JavaScript.

Aborda explícitamente el problema de las interfaces en javascript varias veces. En javascript, las interfaces son más una convención, por lo que depende de usted cómo definirlas. Puede escribir una definición de objeto vacía (piénselo como una clase abstracta o una interfaz). O puede confiar en documentación para sus protocolos/contratos.

En un nivel más conceptual, las firmas de métodos de un objeto definen implícitamente su interfaz, por lo que en javascript a menudo se puede pasar con "pato-tipado" y aún adherirse a SOLID. (!) Este es un ejemplo del "principio de la segregación interfaz" de la presentación que demuestra esto:

// 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; 
}; 

Este código y todo el resto del código de ejemplo de la charla se publica en GitHub: https://github.com/derickbailey/solid-javascript

0

La mayoría de los directores SOLIDOS dependen de la abstracción. En otros lenguajes como Java, podemos hacer abstracciones mediante el uso de interfaces, y Javascript no tiene interfaces. ¿Eso significa que no podemos lograr principios SÓLIDOS en Javascript? La respuesta es No. Este es un gran artículo para aclarar las cosas.

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

En consecuencia, JavaScript es un lenguaje de tipos débiles y no tiene soporte para la abstracción clásica. Hemos intentado lograr la abstracción en JavaScript definiendo interfaces y usándolas. Sin embargo, las interfaces no afectan en absoluto nuestro código. No son más que una forma de documentar el código para los seres humanos. Todos los ejemplos que hemos mostrado arriba funcionarían exactamente igual incluso si eliminamos completamente las interfaces. Sin embargo, se trata de hacer los roles explícitos. Esto aumenta la legibilidad, comprensibilidad y mantenimiento del código.

En general, el objetivo principal de principios sólidos es hacer que el código legible y fácil de modificar, Aplicación de sólidos a su código tiene que ver con tratar de no repetir a ti mismo y hacer que el código más limpio y atractivo.

Cuestiones relacionadas