Programación de objetos y programación de procedimientos
Orientado a objetos consiste en descomponer las transacciones que constituyen el problema en varios objetos. El propósito de crear un objeto no es completar un paso, sino describir el comportamiento de algo en todo el paso de resolución del problema.
Por ejemplo, en la idea de diseño del proceso de backgammon, el primer paso es analizar el problema: 1. Iniciar el juego, 2. La piedra negra se mueve primero, 3. Hacer un dibujo, 4. Juzga ganando o perdiendo, 5. Es el turno de las blancas, 6. Haz un dibujo, 7, juzga ganando o perdiendo, 8, regresa a los pasos 2 y 9, genera el resultado final. Si cada paso anterior se implementa con una función separada, el problema se resuelve.
El diseño orientado a objetos consiste en resolver problemas desde otra forma de pensar. Todo el backgammon se puede dividir en dos bandos, 1 y blanco y negro, que se comportan exactamente igual. 2. El sistema de tablero de ajedrez es responsable de hacer dibujos. 3. El sistema de reglas es responsable de juicios como faltas, ganar y perder, etc. El primer objeto (objeto jugador) es responsable de aceptar la entrada del usuario y notificar al segundo objeto (objeto tablero) de los cambios en el diseño de las piezas de ajedrez. El objeto tablero de ajedrez es responsable de recibir los cambios de las piezas de ajedrez y mostrar los cambios en la pantalla. Al mismo tiempo, el tercer objeto (el sistema de reglas) se utiliza para juzgar el juego de ajedrez.
Se puede ver claramente que la orientación a objetos divide los problemas según funciones en lugar de pasos. Lo mismo ocurre con los dibujos de ajedrez. Este comportamiento está disperso en el diseño total orientado a procesos de múltiples pasos, y es probable que aparezcan diferentes versiones de dibujo, porque los diseñadores generalmente hacen varias simplificaciones considerando la situación real. En el diseño orientado a objetos, el dibujo sólo puede aparecer en el objeto del tablero de ajedrez, asegurando así la unidad del dibujo.
La unificación de funciones asegura la escalabilidad del diseño orientado a objetos. Por ejemplo, si quiero cambiar el diseño orientado al proceso, se debe cambiar una serie de pasos desde la entrada hasta el juicio y la visualización, e incluso se debe ajustar el orden entre los pasos a gran escala. Si está orientado a objetos, solo es necesario cambiar el objeto del tablero de ajedrez. El sistema de tablero de ajedrez guarda los registros de ajedrez en blanco y negro y solo requiere un simple retroceso, mientras que la visualización y el juicio de las reglas no se tienen en cuenta. Al mismo tiempo, toda la secuencia de llamada de la función del objeto no ha cambiado, solo han cambiado partes.
Para otro ejemplo, quiero cambiar este juego de backgammon a un juego de Go. Si está orientado a los procesos, las reglas del backgammon se distribuyen en cada rincón de su programa. Si desea cambiarlo, es mejor reescribirlo. Pero si comienza con el diseño orientado a objetos, entonces sólo necesitará cambiar los objetos de regla. ¿No es la diferencia entre backgammon y go sólo una regla? Claro, los tamaños de los tableros parecen ser diferentes, pero ¿crees que eso es un problema? Simplemente haga un pequeño cambio directamente en el objeto del tablero de ajedrez. ) y los pasos generales del juego de ajedrez no han cambiado desde una perspectiva orientada a objetos.
Por supuesto, para lograr sólo cambios parciales, el diseñador necesita tener suficiente experiencia. El uso de objetos no garantiza que su programa esté orientado a objetos. Es probable que los programadores novatos o deficientes estén orientados a objetos en realidad. Es difícil que los llamados programas orientados a objetos diseñados de esta manera tengan una buena portabilidad y escalabilidad.
También admiro la explicación clara y completa del redactor. Si no lo entiende, puede solicitar más detalles