¿Cómo rompo mis hábitos de codificación de procedimientos?

Question

Hace poco leí un interesante comentario sobre la programación orientada a objetos relacionados question en el que un usuario se opuso a la creación de una clase de "Administrador":

Por favor, elimine la palabra gestor de de su vocabulario al hablar sobre nombres de clase. El nombre de la clase debe ser descriptivo de su propósito ' . Manager es solo otra palabra para vertedero. Cualquier funcionalidad encajará allí. La palabra ha sido la causa de muchos malos diseños extremadamente

Este comentario representa mi lucha para convertirse en un buen desarrollador orientado a objetos. He estado haciendo un código de procedimiento durante mucho tiempo en una organización con solo codificadores de procedimientos. Parece que la principal estrategia detrás del relativamente pequeño código OO que producimos es dividir el problema en clases que son fácilmente identificables como unidades discretas y luego poner los bits sobre/generalizados en una clase "Manager".

¿Cómo puedo romper mis hábitos de procedimiento (como la clase Manager)? La mayoría de los artículos/libros de OO, etc. usan ejemplos de problemas que son intrínsecamente fáciles de transformar en grupos de objetos (por ejemplo, Vehículo -> Automóvil) y, por lo tanto, no proporcionan mucha orientación para analizar sistemas más complejos.

Answer 1

El single responsibility principle me ayuda a dividir los objetos en clases manejables que tengan sentido.

Cada objeto debe hacer una cosa, y hacerlo bien sin exponer cómo funciona internamente para otros objetos que necesitan usarla.

Answer 2

Puede aprender buenos principios de diseño orientados a objetos estudiando design patterns. Code Complete 2 es un buen libro para leer sobre el tema. Naturalmente, la mejor manera de incorporar buenos principios de programación en su mente es practicarlos constantemente aplicándolos a sus propios proyectos de codificación.

Answer 3

Leer y practicar principios OO es lo que funciona para mí. Head First Object-Oriented Analysis & Design le muestra los ejemplos para hacer una solución que sea OO y luego formas de mejorar la solución.

Answer 4

A 'administrador' clase a menudo se:

estado de
1. interogate algo
2. Tomar una decisión basada en ese estado

Como antídoto o contraste con esto, el diseño Orientado a Objetos haría Lo invitamos a diseñar API de clase en las que "diga, no pida" a la clase que haga las cosas por sí misma (y encapsule su propio estado): para obtener más información sobre "diga, no pregunte", consulte, por ejemplo, here y here (y tal vez alguien más tenga una mejor explicación de "no preguntar", pero estos son los primeros dos artículos que Google encontró para mí).

Parece que la estrategia principal de la pequeña de código orientado a objetos que producimos es para romper el problema en las clases que son fácilmente identificables como unidades discretas y luego poner los sobrantes bits/generalizadas en una clase de "Administrador".

Eso puede ser cierto incluso en el mejor de los casos. Coplien hablado de esto hacia el final de su avanzada C++: Programación Estilos y modismos libro: dijo que en un sistema, que tienden a tener:

• objetos autónomos
• Y, "transacciones" , que actúan sobre otros objetos

Tomemos, por ejemplo, un avión (y lo siento por darle otro ejemplo vehicular; lo estoy parafraseando):

• Los 'objetos' pueden incluir los alerones, el timón, y el empuje
• El 'administrador' o autpilot implementaría varios comandos o transacciones

Por ejemplo, el "girar a la derecha" transacción incluye:

• flaps.right.up()
• flaps.left.down()
• rudder.right()
• thrust.increase()

Así que creo que es cierto que tiene transacciones, que atraviesan o usan los diversos 'objetos' relativamente pasivos; en una aplicación, por ejemplo, el comando de usuario "cualquiera" terminará siendo implementado por (y por lo tanto, invocando) varios objetos de cada capa (por ejemplo, la interfaz de usuario, la capa intermedia y la capa de base de datos).

Entonces, creo que es cierto que hasta cierto punto tendrá 'bits sobrantes'; sin embargo, es una cuestión de grado: tal vez debería querer tanto del código como sea posible para ser autónomo, y encapsular, y todo ... y los bits sobrantes, que usan (o dependen de) todo lo demás, debe darse/usar una API que oculte tanto como sea posible y que haga tanto como sea posible, y que, por lo tanto, tome tanta responsabilidad (detalles de implementación) como sea posible, lejos del llamado administrador.

Lamentablemente, solo he leído este concepto en ese libro (Advanced C++) y no puedo vincularlo con algo en línea para obtener una explicación más clara que esta paráfrasis.

Answer 5

Antes que nada, dejaría de actuar como si el código de procedimiento fuera incorrecto. Es la herramienta correcta para algunos trabajos. OO es también la herramienta adecuada para algunos trabajos. Entonces es funcional. Cada paradigma es solo un punto de vista diferente de la computación, y existe porque es conveniente para ciertos problemas, no porque sea la única forma correcta de programar. En principio, los tres paradigmas son matemáticamente equivalentes, por lo tanto, use el que mejor corresponda con el dominio del problema. En mi humilde opinión, si se usa un lenguaje multiparadigm, incluso está bien mezclar paradigmas dentro de un módulo si diferentes subproblemas se modelan mejor mediante diferentes visiones del mundo.

En segundo lugar, leí los patrones de diseño. Es difícil entender OO sin algunos ejemplos de los problemas del mundo real que es bueno para resolver. Head First Design Patterns es una buena lectura, ya que responde mucho al "por qué" de OO.

Answer 6

¿Cuántos programadores OOP se necesitan para cambiar una bombilla?

Ninguno, la bombilla cambia por sí misma.

;)

Answer 7

Creo que debería empezar con un buen plan. planificar usando diagramas de clase sería un buen comienzo.

debe identificar las ENTIDADES necesarias en la aplicación, , luego definir los ATRIBUTOS y MÉTODOS de cada entidad. si hay repeticiones, ahora podría volver a definir sus entidades de forma que se pueda realizar la herencia, para evitar redundancia. : D.

Answer 8

Puede jugar con un lenguaje OO que tiene muy mal soporte de procedimientos como Smalltalk. El paradigma de envío de mensajes te forzará a pensar OO.

Answer 9

Ser bueno en OO requiere años de práctica y estudio del buen código OO, idealmente con un mentor. Recuerde que OO es solo un medio para un fin. Dicho esto, aquí hay algunas pautas generales que funcionan para mí:

• Favorecer la composición sobre la herencia. Lea y vuelva a leer el primer capítulo de GoF book.
• Obedezca el Law of Demeter ("dígale, no pregunte")
• Intente utilizar la herencia solo para lograr el polimorfismo. Cuando extienda una clase de otra, hágalo con la idea de que invocará el comportamiento de esa clase a través de una referencia a la clase base. ALL los métodos públicos de la clase base deberían tener sentido para la subclase.
• No se obsesione con el modelado. Construya un prototipo funcional para informar su diseño.
• Embrace refactoring. Lea los primeros capítulos de Fowler's book.

Answer 10

Mi momento eureka para entender el diseño orientado a objetos fue cuando leí el libro de Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software". O el mini-libro "Domain Driven Design Quickly" (que está disponible en línea como un PDF gratuito) si es barato o impaciente. :)

Cada vez que tiene una clase "Manager" o instancias de singleton estáticas, probablemente esté creando un diseño de procedimiento.

Answer 11

¿Cómo puedo romper mis hábitos de procedimiento (como la clase Manager)?

Realice una clase para lo que el administrador está gestionando (por ejemplo, si tiene una clase ConnectionManager, cree una clase para una conexión). Mueve todo a esa clase.

La razón por la cual "manager" es un nombre deficiente en OOP es que una de las ideas principales en OOP es que los objetos deberían administrarse ellos mismos.

No tenga miedo de hacer pequeñas clases. Viniendo de un procedimiento de fondo, puede pensar que no vale la pena el esfuerzo para hacer una clase a menos que sea un millar de líneas de código y es algún concepto central en su dominio. Piense más pequeño. Una clase de diez líneas es totalmente válida. Haga pequeñas clases donde vea que tienen sentido (una fecha, una dirección de correo) y luego siga subiendo componiendo clases.

Cuando empiece a dividir pequeñas partes de su código base en clases, la sopa de código de procedimiento restante se reducirá. En ese grupo de contracción, comenzarás a ver otras cosas que pueden ser clases. Continúa hasta que el grupo esté vacío.

Answer 12

Tengo un proceso de tres pasos, este es uno que he pasado con éxito yo mismo. Más tarde conocí a un ex profesor convertido en programador (ahora con mucha experiencia) que me explicó exactamente por qué este método funcionó tan bien, hay un poco de psicología involucrada, pero básicamente se trata de mantener el control y la confianza a medida que aprendes. Aquí está:

1. Conozca qué es el desarrollo de prueba (TDD). Puede hacerlo cómodamente con el código de procedimiento, por lo que no necesita comenzar a trabajar con objetos aún si no lo desea. El segundo paso depende de esto.

2. Elija una copia de Refactoring: Mejorando el Diseño de Código Existente por Martin Fowler. Básicamente es un catálogo de pequeños cambios que puedes hacer al código existente. Sin embargo, no puedes refactorizar correctamente sin pruebas. Lo que esto le permite hacer es meterse con el código sin preocuparse de que todo se romperá. Las pruebas y la refactorización le quitan la paranoia y sienten que no sabe lo que sucederá, lo cual es increíblemente liberador. Te fuiste para jugar básicamente. A medida que tenga más confianza con ese comienzo, explore burlas para probar las interacciones entre objetos.

3. Ahora viene lo grande que la mayoría de las personas, erróneamente comienzan con, es bueno pero realmente debería ser el tercero. En este punto, puede leer sobre los patrones de diseño, los olores de código (que es bueno para Google) y los principios de diseño orientado a objetos. También aprenda sobre historias de usuarios o casos de uso, ya que le ofrecen buenas clases de candidatos iniciales al escribir nuevas aplicaciones, que es una buena solución para "¿dónde empiezo?" problema al escribir aplicaciones.

Y eso es todo! Bondad probada! Déjame saber como va.