que - Escribir JavaScript de acuerdo con SOLID
javascript tutorial (5)
¿Alguien ha usado el principio de programación SÓLIDA (o cualquiera de sus partes) mientras desarrolla JavaScript?
Acabo de comenzar a leer sobre él, 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 hay interfaces en JS (bueno, si lo fuera).
Esta presentación: SOLID JavaScript In A Wobbly (World Wide Web) de Derick Bailey demuestra cómo utilizar principios de programación SÓLIDOS mientras desarrolla 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 la documentación de 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 todavía adherirse a SOLID. (!) Aquí hay un ejemplo del "principio de segregación de 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
Esta respuesta aceptada es defectuosa. Recomiendo leer los cinco artículos vinculados por Ryan Rensford a continuación. El último artículo llega a la siguiente conclusión que no comuniqué (énfasis mío):
Mientras que en el curso de nuestro examen vimos variaciones en cómo los principios de diseño SOLID se aplican a JavaScript sobre otros idiomas, cada uno de los principios mostró 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 sobre OOP en JS que también llega a esa conclusión.
Hay algunos enfoques de OOP en Prototype.js, CoffeeScript y John Resigs Herencia de JavaScript simple (cada uno con sus propias trampas).
Pero la terminología (interfaces, abstracción) de SOLID es difícil de aplicar al JavaScript estándar de una 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.
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 orientado a objetos)
Tal vez muchos desarrolladores lo desprecian porque muchos de ellos están acostumbrados a ver prácticas de programación deficientes y, en consecuencia, un comportamiento defectuoso 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
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 débilmente tipado y no tiene soporte clásico para la abstracción. 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 los principios SOLID es hacer que el código sea legible y fácil de modificar, aplicar SOLID a su código se trata de tratar de no repetirse y hacer que su código sea más agradable y limpio.
Parece que Derek Greer intenta apuñalar esto con su serie de artículos sobre SOLID JavaScript en Fresh Brewed Code: