Factoring y herencia en c ++

El concepto de herencia, y por lo tanto el factoring, en C ++ permite a una clase a heredar las propiedades de una clase base. La herencia tiene una serie de purposes- el principal beneficio de la herencia es la capacidad de señalar la relación entre las clases. Esta es la llamada ES UN relación - un Homo de microondas ES_UN Horno Y cosas como esa.

El factoraje es una gran cosa si usted hace las correlaciones correctas. Por ejemplo, el horno de microondas frente a la relación horno convencional parece natural. Reclama que microondas es un tipo especial de la tostadora, y que está dirigido a los problemas. Es cierto que ambos hacen cosas calientes, ambos usan la electricidad, y ambos son encontrados en la cocina, pero la similitud termina ahí - un microondas no puede hacer tostadas y una tostadora no puede hacer nachos.

La identificación de las clases inherentes a un problema y dibujar las relaciones correctas entre estas clases es un proceso conocido como factoring. (La palabra se relaciona con la aritmética que se vieron obligados a hacer en la escuela primaria: factorizar los denominadores menos comunes, por ejemplo, 12 es igual a 2 veces 2 veces 3.)

He aquí cómo usted puede utilizar la herencia para simplificar sus programas utilizando un ejemplo de cuenta bancaria. Suponga que se le pidió escribir un programa de banco simple que implementa el concepto de una cuenta de ahorros y una cuenta de cheques.

Programadores orientados a objetos han llegado con una forma concisa para describir los puntos más destacados de una clase en un dibujo. los Comprobación y Ahorros clases se muestran en esta figura. (Esta es sólo una de las varias formas de expresar gráficamente lo mismo.)

Para leer esta cifra y las otras figuras, recuerde lo siguiente:

• La caja grande es la clase, con el nombre de la clase en la parte superior.

• Los nombres en las cajas son funciones miembro.

• Los nombres no en cajas son miembros de datos.

• Los nombres que se extienden hasta la mitad de las cajas son públicamente accesibles miembros- es decir, estos usuarios pueden tener acceso a funciones que no son parte de la clase o de cualquiera de sus descendientes. Aquellos miembros que están completamente dentro de la caja no son accesibles desde fuera de la clase.

• Una flecha gruesa representa la ES UN relación.

• Una flecha delgada representa el TIENE UN relación.

LA Coche ES_UN Vehículo, pero una Coche HAS_A Motor.

Se puede ver en la primera figura que el Comprobación y Ahorros clases tienen mucho en común. Por ejemplo, ambas clases tienen una retirada () y depósito () función miembro. Debido a que las dos clases no son idénticos, sin embargo, deben permanecer como clases separadas. (En una aplicación bancaria en la vida real, las dos clases serían bastante más diferente que en este ejemplo). Aún así, debe haber una manera de evitar esta repetición.

Usted podría tener una de estas clases heredan de la otra. Ahorros tiene más miembros que Comprobación, por lo que podría dejar Ahorros heredar de Comprobación. Esta disposición se muestra en la siguiente figura.

los Ahorros clase hereda todos los miembros. La clase se completa con la adición del miembro de datos noWithdrawals y reemplazando la función retirada (). Usted tiene que anular retirada () porque las reglas para retirar dinero de una cuenta de ahorros son diferentes de aquellos para retirar dinero de una cuenta corriente.

Aunque dejar Ahorros heredar de Comprobación se ahorran trabajo, no es completamente satisfactoria. El principal problema es que, al igual que el peso que aparece en el carnet de conducir, se tergiversa la verdad. Esta relación de herencia implica que una cuenta de ahorros es un tipo especial de cuenta de cheques, que no lo es.

Tales tergiversaciones son confusas para el programador, tanto de hoy y de mañana. Algún día, un programador familiarizado con nuestros trucos de programación tendrá que leer y entender lo que hace nuestro código. Representaciones engañosas son difíciles de conciliar y comprender.

Además, tales declaraciones falsas pueden conducir a problemas en el futuro. Supongamos, por ejemplo, que el banco cambia sus políticas con respecto a las cuentas de cheques. Digamos que decide cobrar una tarifa de servicio de cuentas de cheques sólo si el saldo mínimo cae por debajo de un valor dado durante el mes.

Un cambio como este puede ser fácilmente manejado con cambios mínimos en la clase Comprobación. Vas a tener que añadir un nuevo miembro de datos a la clase Comprobación no perder de vista el saldo mínimo durante el mes. Vamos a salir en una extremidad y lo llaman minimumBalance.

Pero ahora usted tiene un problema. Porque Ahorros hereda de Consultando su ahorro consigue este nuevo miembro de datos también. No tiene ningún uso para este miembro porque el saldo mínimo no afecta a las cuentas de ahorro, por lo que sólo se sienta allí. Recuerde que cada objeto cuenta corriente tiene este accesorio minimumBalance miembro. Un miembro de datos adicional puede no ser un gran problema, pero añade más confusión.

Los cambios de este tipo se acumulan. Hoy es un miembro de datos adicional - mañana es una función miembro cambiada. Con el tiempo, la cuenta de ahorros de clase está llevando un montón de equipaje extra que sólo es aplicable a las cuentas de cheques.

Ahora el banco regresa y decide cambiar algunos ahorros representan la política. Para ello, debe modificar alguna función en Comprobación. Los cambios de este tipo en la clase base se propagan automáticamente a la subclase a menos que la función ya se anula en la subclase Ahorro.

Por ejemplo, supongamos que el banco decide regalar tostadoras por cada depósito en la cuenta corriente. Sin el banco (o sus programadores) saberlo, depósitos a cuentas de cheques se traduciría automáticamente en donaciones tostadora. A menos que seas muy cuidadoso, cambia a Comprobación puede aparecer inesperadamente en Ahorro.

¿Cómo puede evitar estos problemas? Afirmar que Comprobación es un caso especial de Ahorros cambios, pero no resuelve nuestro problema. Lo que necesita es una tercera clase (llámese Cuenta, sólo para sonríe) que encarna las cosas que son comunes entre Comprobación y Ahorros, como se muestra aquí.

¿De qué manera la construcción de una nueva cuenta de la solución de los problemas? En primer lugar, la creación de un nuevo Cuenta clase es una descripción más exacta del mundo real (sea lo que sea). Por supuesto, en realidad es algo que se conoce como una cuenta. Las cuentas de ahorro y cuentas corrientes son casos especiales de este concepto más fundamental.

Además, la clase Ahorros está aislado de los cambios en la clase Comprobación (y viceversa). Si los institutos bancarios un cambio fundamental para todas las cuentas, puede modificar Cuenta, y todas las subclases heredarán automáticamente el cambio. Pero si el banco cambia su política sólo para cuentas de cheques, puede modificar sólo el Comprobación clase cuenta sin afectar Ahorro.

Este proceso de sacrificio de las propiedades comunes de las clases similares es la esencia de clase de factoring.

El factoraje es legítima sólo si la relación de herencia corresponde a la realidad. Factoring juntos una clase Ratón y Joystick porque son tanto de hardware como dispositivos señaladores es legítimo. Factoring juntos una clase Ratón y Display porque ambos hacen de bajo nivel llamadas al sistema operativo que no es.