oop - software - solid poo

Parece que no se pueden entender los principios y patrones de diseño SOLID

Question

Estoy tratando de entrar en OOP últimamente, y estoy teniendo problemas con los principios y los patrones de diseño de SOLID . Veo por qué la gente los usa y realmente quiero usarlos también, pero no puedo concentrarme en desarrollar mis clases de acuerdo con las especificaciones. Realmente apreciaría cualquier cosa que me ayude a entender esto.

Answer 1

Tomé una clase en la universidad que pasó dos semanas en torno a los patrones de diseño, y leí el libro Gang of Four sin éxito. Comprender para qué servía cada patrón y cómo usarlos para resolver mis problemas fue muy difícil para mí, un desarrollador que no tenía mucha experiencia en la programación OO.

El libro que realmente me hizo clic fue Head First Design Patterns . Comienza mostrando un problema, diferentes enfoques que los desarrolladores consideraron, y luego cómo terminaron usando un patrón de diseño para solucionarlo. Utiliza un lenguaje muy simple y mantiene el libro muy atractivo.

Los patrones de diseño terminan siendo una forma de describir una solución, pero no tiene que adaptar sus clases a la solución. Piense en ellos más como una guía que sugiere una buena solución para una amplia gama de problemas.

Hablemos de SOLID:

1. Única responsabilidad . Una clase debe tener una sola responsabilidad. Eso significa que, por ejemplo, una clase de Persona solo debería preocuparse por el problema del dominio relacionado con la persona en sí, y no por ejemplo, su persistencia en la base de datos. Para eso, es posible que desee utilizar un PersonDAO, por ejemplo. Una clase de persona puede querer mantener sus responsabilidades lo más corto posible. Si una clase usa demasiadas dependencias externas (es decir, otras clases), eso es un síntoma de que la clase tiene demasiadas responsabilidades. Este problema a menudo surge cuando los desarrolladores intentan modelar el mundo real utilizando objetos y llevarlo demasiado lejos. Las aplicaciones de acoplamiento flexible a menudo no son muy fáciles de navegar y no modelan exactamente cómo funciona el mundo real.
2. Abierto Cerrado . Las clases deben ser extensibles, pero no modificables. Eso significa que agregar un nuevo campo a una clase está bien, pero cambiar las cosas existentes no lo es. Otros componentes en el programa pueden depender de dicho campo.
3. Sustitución de Liskov . Una clase que espera un objeto de tipo animal debería funcionar si se pasan un subclase dog y un subclass cat. Eso significa que Animal NO debe tener un método llamado ladrido, por ejemplo, ya que las subclases de tipo cat no podrán ladrar. Las clases que usan la clase Animal, tampoco deberían depender de los métodos que pertenecen a una clase Dog. No hagas cosas como "Si este animal es un perro, entonces (arroja de animal a perro) la corteza. Si el animal es un gato entonces (arroja de animal a gato) miau".
4. Principio de segregación de interfaz . Mantenga sus interfaces lo más pequeño que pueda. Un maestro que también es un estudiante debe implementar las interfaces IStudent y ITeacher, en lugar de una sola interfaz grande llamada IStudentAndTeacher.
5. Principio de inversión de la dependencia . Los objetos no deben crear instancias de sus dependencias, sino que deben pasárseles. Por ejemplo, un Coche que tiene un objeto de Motor dentro no debe hacer engine = new DieselEngine (), sino que dicho motor debe pasarse a él en el constructor. De esta manera, la clase de automóvil no se acoplará a la clase DieselEngine.