Diseño avanzado de clases en C++

Antes de comenzar a aprender las nuevas funciones avanzadas de C ++, necesitamos hablar sobre algunos de los principios de buen diseño de clase. ¿Por qué es importante un buen diseño de clase? Eso es porque sin un buen diseño de clase, la capacidad de ampliar la funcionalidad del software o agregar nuevas funciones se ve seriamente disminuido. Así que hablemos de algunos de los principios. que son más útiles y comencemos con el principio llamado SECO. DRY es un acrónimo que significa no te repitas, lo que significa que debes escribir código para hacer algo o describir algo una vez y solo una vez. ¿Entonces que significa eso exactamente? Echemos un vistazo a un ejemplo. Tienes una clase llamada DoNotRepeat, que está resaltado. Y esa clase tiene algunas variables, algunas variables miembro llamadas integer_var, double_var y string_var. También tiene funciones para configurar esas variables y también recuperar sus valores. Ahora consideremos la otra clase, llamada esta clase repetida. Fíjate que tiene un diseño muy similar. Tiene una variable miembro similar llamada integer_var, double_var, string_var y tiene funciones de interfaz similares para establecer esas variables y recuperar algunos de sus valores, sino también para calcular algún otro valor basado en esos valores. Entonces, si miras estas 2 clases y entenderás que si necesita cambiar una función, que es lo mismo entre ellos, probablemente necesitará hacer cambios dos veces. Deberá cambiar DoNotRepeat y luego también necesitará cambiar Repetido, que es, por supuesto, prácticamente posible, pero muy mala idea porque cambios en el código que deben repetirse 2, 3, 4 veces es una muy buena forma de introducir errores en su programa. Entonces C ++ te proporciona un mecanismo que te permitirá escribir el código que es común entre las 2 clases una vez y solo una vez, que se llama herencia. Y estaremos hablando de eso en algunas de las secciones siguientes. Otro principio que necesitamos hablar es encapsulación. Y ese principio es realmente muy importante. La encapsulación es un principio por el cual las propiedades del objeto está protegido del acceso directo por funciones o clases externas. Esto no es lo único que necesita la encapsulación. Los objetos correctamente encapsulados tienen una interfaz muy estrecha, lo que significa que un usuario externo solo puede hacer algunas cosas con los objetos, pero la cantidad de componentes y funciones internas dentro del objeto pueden ser grandes y podrían hacer algunas cosas por su cuenta, pero no puedes realizar esas funciones sin acceder a la interfaz del objeto encapsulado. Para este ejemplo, echemos un vistazo a una clase de objeto llamada Mixer, que describe una batidora de cocina de pie. En mi ejemplo Estoy describiendo una batidora Kitchen Aid y, como puede ver, tiene una interfaz muy sencilla. Puede iniciarlo, detenerlo, mezclar. Puede quitar la taza, puede instalar la taza, puede desbloquear el mezclador, bloquear el mezclador, y también puedes subir la batidora. Esas son las únicas funciones que puede realizar en el objeto correctamente encapsulado. También sabes que la batidora contiene engranajes, motor, controlador y algunos otros componentes, pero no tienes acceso a ellos como usuario normal del objeto. Sabes que existen individualmente. Te interesan muy poco y no tienes necesidad de controlarlos o tener la función de controlarlos excepto a través del objeto. El siguiente principio que veremos se denomina principio de responsabilidad única. Esta es una forma elegante de decir esa clase debería ser responsable de una cosa y una sola cosa. Si una clase, por ejemplo, es responsable de describir una orden de venta, no debe ser responsable de guardar la información de esa orden de venta a la base de datos ni debe ser responsable de convertirse a otro formato como XML. ¿Por qué no es una buena idea? Bueno, en realidad es muy simple. Sí mismo a la base de datos, por ejemplo, el objeto necesita tener la información de la base de datos. Entonces, si tiene muchos pedidos de venta, cada uno debe tener una copia de la información de la base de datos, que es propenso a errores y hace que el código sea realmente confuso de leer y muy difícil de mantener. Entonces, a menos que sea absolutamente necesario, Deben evitarse dependencias como estas. El último principio del que hablaremos en este apartado se llama el principio abierto-cerrado. El principio establece que la clase debe estar abierta a la extensión, pero cerca de la modificación. ¿Entonces que significa eso exactamente? Echemos un vistazo a algo para la validación de reglas. Tienes una clase llamada RuleValidation, que tiene un método de interfaz llamado regla de validación al que le pones un objeto de regla, que puede describir usted mismo. Y luego tienes la lógica de validación en el método y significa que cada vez que agregas una nueva regla o un nuevo tipo de validación, tendrás que cambiar la clase RuleValidation para adaptarse a la nueva funcionalidad. Una mejor manera de hacer esto sería tener una clase llamada ValidateRule, que tendrá una función pública llamada validar. Entonces, para cada tipo de validación que desee, creará un objeto de esta clase. Y puede extender esto nuevamente usando herencia. Puedes extenderlo por, proporcionar tipos específicos de validación. Y luego realmente puede tener la validación de reglas, tener un conjunto de objetos de reglas de validación, que validan llamaremos sucesivamente hasta que consiga que la regla es válida, o les fallará a todos. De esta forma, el objeto de validación de la regla no tiene que cambiar mucho para adaptarse a nuevas reglas de validación. Lo único que necesitarás para agregar es una función llamada addRuleValidator, que tomará el objeto de la regla de validación, y los agregaré al conjunto de validación. Agregue la regla de validación. Y luego, simplemente puede agregar muchas validaciones tantas validaciones como desee, que es exactamente como se describe en el principio abierto-cerrado.