6.3Problemas de diseo y aplicacin Definicin de buenas interfaces de clase va un largo camino hacia la creacin de una alta calidad programa.

El diseo y la implementacin de la clase interna tambin son importantes. Este seccin trata sobre temas relacionados con la contencin, la herencia, las funciones miembro y los datos, acoplamiento de clase, constructores, y los objetos de valor contra-referencia. Contencin ("tiene una" relacion) La contencin es la simple idea de que una clase contiene un elemento o datos primitivo objeto. Mucho ms se escribe sobre la herencia de alrededor de contencin, si bien es porque la herencia es ms complicado y propenso a errores, no porque sea mejor. La contencin es la tcnica de caballo de trabajo en la programacin orientada a objetos. Implentacion mediante la contencion Una forma de pensar de la contencin es como "tiene una" relacin. Por ejemplo, una empleado "tiene un" nombre ", tiene un" nmero de telfono ", tiene un" nmero de identificacin fiscal, y as sucesivamente. Usted por lo general puede lograr esto haciendo que el nombre, nmero de telfono o de identificacin fiscal datos de los miembros del Empleado clase. Implementar mediante la herencia privada como ltimo recurso En algunos casos puede encontrarse con que no se puede lograr a travs de la contencin toma un objeto de un miembro de otra. En ese caso, algunos expertos sugieren heredando privada del objeto contenido (Meyers 1998). La razn principal Haras eso es la creacin de la clase que contiene acceder miembro protegido funciones o datos de la clase que est contenido. En la prctica, este enfoque crea una relacin demasiado acogedor con la clase ancestro y viola la encapsulacin. Lo tiende a apuntar a los errores de diseo que debe resolverse alguna manera que no sea a travs de la herencia privada. Sea crtico de clases que contienen ms de siete miembros El nmero "7 2" se ha encontrado que es un nmero de elementos discretos que una persona puede recordar mientras realiza otras tareas (Miller 1956). Si una clase contiene ms de unos siete miembros de datos, considere si la clase debe ser descompuesto en varias otras ms pequeas (Riel 1996). Usted puede errar ms hacia el extremo superior de 7 2 si los miembros de datos son tipos de datos primitivos como enteros y cadenas, mas hacia el extremo inferior de 7 2, si los miembros de datos son objetos complejos. Herencia ("es una" relacion) La herencia es la idea compleja que una clase es una especializacin de otra clase. La herencia es quizs la caracterstica ms distintiva de la orientada a objetos programacin, y debe ser utilizado con moderacin y con mucha precaucin. Una gran muchos de los problemas en la programacin moderna surgen del uso demasiado entusiasta de la herencia. El propsito de la herencia es crear cdigo ms simple mediante la definicin de una clase base que especifica los elementos comunes de dos o ms clases derivadas. El comn los elementos pueden ser interfaces de rutina, implementaciones, los miembros de datos, o datos tipos. Cuando usted decide utilizar la herencia, hay que tomar varias decisiones:

 Para cada miembro de la rutina, la rutina va ser visible para las clases derivadas? Voluntad que tiene una implementacin predeterminada? Ser la aplicacin por defecto reemplazable? Para cada miembro de datos (incluyendo variables, llamadas constantes, numeraciones, y as sucesivamente), ser el miembro de datos ser visible para las clases derivadas? Los siguientes apartados explican los pormenores de la toma de estas decisiones. Poner en prctica "es un" medio de la herencia pblica Cuando un programador decide crear una nueva clase heredando de una existente clase, que el programador est diciendo que la nueva clase "es un" ms especializado versin de la clase mayor. La clase base establece expectativas sobre cmo el derivado clase funcionar (Meyers 1998). Si la clase derivada no va a adherirse completamente a la misma interfaz contrato definido en la clase base, la herencia no es la aplicacin correcta tcnica. Considere la posibilidad de contencin o hacer un cambio ms arriba en la herencia jerarqua. El nico y ms importante regla en objetos programacin orientada con C + + es este: public herencia significa "isa". Comprometerse esta regla a memoria. -Scott Meyers Diseo y documentacin de la herencia o prohibida, Herencia aade complejidad a un programa, y, como tal, es un peligroso tcnica. Como Java gur de Joshua Bloch dice: "El diseo y el documento de herencia, o la prohbe. "Si una clase no est diseada para ser heredado, har su miembros no virtuales en C + +, ltimo en Java, o no reemplazable en Visual Basic para que no se puede heredar de ella. Adherirse al principio de sustitucin Liskov En uno de los documentos fundacionales de la programacin orientada a objetos, Barbara Liskov argument que no se debe heredar de una clase base a menos que la clase derivada verdad "es una" versin ms especfica de la clase base (Liskov 1988). Andy Hunt y David Thomas sugiere una buena prueba de fuego para esto: "Las subclases deben ser utilizables a travs la interfaz de la clase base sin la necesidad de que el usuario conozca la diferencia " (Hunt y Thomas 2000). En otras palabras, todas las rutinas definidas en la clase base deben significar lo mismo cosa cuando se usan en cada una de las clases derivadas. Si usted tiene una clase base de la cuenta , y las clases derivadas de CuentaCorriente , SavingsAccount , y AutoLoanAccount , un programador debe ser capaz de invocar cualquiera de las rutinas de deriva de cuenta en cualquiera de Cuenta subtipos 's sin preocuparse por qu subtipo de un objeto de cuenta especfico. Si un programa ha sido escrito para que el principio de sustitucin Liskov es cierto, herencia es una herramienta poderosa para reducir la complejidad debido a que un programador puede centrarse en los atributos genricos de un objeto sin tener que preocuparse por los detalles. Si, un programador debe ser constantemente pensando en las diferencias semnticas en la subclase implementaciones, a continuacin, la herencia es cada vez mayor complejidad en lugar de reducir ella. Supongamos que un programador tiene que pensar: "Si llamo al InterestRate () de rutina en CuentaCorriente o SavingsAccount , devuelve el inters que el banco paga, pero si llame InterestRate () en AutoLoanAccount tengo que cambiar el signo, ya que devuelve el inters que el

consumidor paga al banco. "Segn Liskov, el InterestRate () rutina no debe ser Heredado por su semntica no son la igual para todas las clases derivadas. Asegrese de heredar slo lo que desea heredar Una clase derivada puede heredar interfaces de miembro de rutina, implementaciones, o ambos. La Tabla 6-1 muestra las variaciones de cmo las rutinas se pueden implementar y anulado. Tabla 6-1. Las variaciones en las rutinas heredadas Como la tabla indica, rutinas heredadas vienen en tres sabores bsicos: Una rutina reemplazable abstract significa que la clase derivada hereda el La interfaz de la rutina, pero no su aplicacin. Una rutina reemplazable significa que la clase derivada hereda la rutina de interfaz y una implementacin predeterminada, y se deja para anular la implementacin predeterminada. Una rutina no reemplazable significa que la clase derivada hereda la rutina de interfaz y su implementacin por defecto, y no se les permite anular el implementacin de la rutina. Si decide implementar una nueva clase a travs de la herencia, pensar a travs de el tipo de herencia que desee para cada miembro de la rutina. Cuidado de heredar aplicacin slo porque usted est heredando una interfaz, y guardaos de heredar una interfaz slo porque desea heredar una implementacin. No "anular" una funcin miembro no reemplazable Tanto C + + y Java permite a un programador para reemplazar un miembro no reemplazable rutina-ms o menos. Si una funcin es privada en la clase base, una clase derivada puede crear una funcin con el mismo nombre. Para el programador de la lectura del cdigo en el clase derivada, esta funcin puede crear confusin porque se ve como debera por polimrfico, pero no lo es, sino que slo tiene el mismo nombre. Otra manera de expresar este directriz es, No vuelva a usar los nombres de las rutinas de la clase base no reemplazables en derivados clases. Mueva interfaces comunes, los datos y el comportamiento lo ms alto posible en el rbol de herencia Cuanto ms alto se mueve interfaces, los datos y el comportamiento, derivado del mayor facilidad las clases pueden utilizarlos. Qu tan alto es demasiado alto? Deje que la abstraccin sea su gua. Si usted encuentra que mover una rutina de alto rompera el objeto de mayor abstraccin, no lo hagas. Desconfe de las clases de los cuales hay una sola instancia Un solo ejemplo puede indicar que el diseo confunde objetos con clases. Considere si usted podra crear un objeto en lugar de una nueva clase. Puede el variacin de la clase derivada puede representar en los datos en lugar de como una clara clase? Desconfe de las clases de base de las cuales slo hay una clase derivada Cuando veo a una clase base que tiene slo una clase derivada, sospecho que algunos

programador ha sido "disear por delante", tratando de anticiparse a las necesidades futuras, por lo general sin entender completamente lo que esas necesidades futuras. La mejor manera de prepararse para el trabajo futuro no es para disear capas extra de clases base que "podra ser necesario algn da ", es para que el trabajo actual, clara, directa y simple como sea posible. Eso significa no crear ms estructura de herencia de es absolutamente necesario. Desconfe de las clases que anulan una rutina y no hacer nada en el interior del rutina derivados Esto normalmente indica un error en el diseo de la clase base. Por ejemplo, suponga que tiene una clase Cat y una rutina de araazos () y supongamos que finalmente descubren que algunos gatos se declawed y no puede rayar. Usted puede ser la tentacin de crear una clase derivada de gato llamado ScratchlessCat y anular el cero () de rutina para no hacer nada. Hay varios problemas con este enfoque: Se viola la abstraccin (contrato de interfaz) se presenta en el Cat clase cambiar la semntica de su interfaz. Este enfoque pone rpidamente fuera de control al extender a otros clases derivadas. Qu ocurre cuando se encuentra un gato sin cola? O un gato eso no cazar ratones? O un gato que no bebe leche? Con el tiempo usted terminar con las clases derivadas como ScratchlessTaillessMicelessMilklessCat . Con el tiempo, este enfoque da lugar a cdigo que es confuso para mantener porque las interfaces y el comportamiento de las clases ancestro implican poco o nada sobre el comportamiento de sus descendientes. El lugar de solucionar este problema no est en la clase base, pero en el original Cat clase. Crear un Claws clase y contener que en el Cats clase, o construir un constructor para la clase que incluye si el gato araa. La raz del problema era el supuesto de que todos los gatos araan, as solucionar el problema en la fuente, en lugar de vendajes que en el destino. Evite los rboles de herencia profundas De programacin orientado a objetos proporciona un gran nmero de tcnicas para la gestin de la complejidad. Pero cada herramienta poderosa tiene sus peligros, y algunos objetos tcnicas orientadas tienen una tendencia a aumentar la complejidad en lugar de reducirla. En su libro excelente orientada a objetos Heurstica Diseo , Arthur Riel sugiere limitando jerarquas de herencia a un mximo de seis niveles (1996). Basa su Riel recomendacin sobre el "nmero mgico 7 2," pero creo que eso es sumamente optimista. En mi experiencia, la mayora de las personas tienen problemas para hacer juegos malabares ms de dos o tres niveles de herencia en el cerebro a la vez. El "nmero mgico 7 2" es probablemente mejor aplicado como un lmite en el nmero total de las subclases de una base clase en vez del nmero de niveles en un rbol de herencia. rboles de herencia profundas se han encontrado para ser asociado significativamente con aumento de las tasas de error (Basili, Briand y Melo 1996). Cualquiera que haya intentado para depurar una jerarqua de herencia compleja sabe por qu. Profunda herencia rboles aumentan la complejidad, que es exactamente lo contrario de lo que la herencia se debe utilizar para llevar a cabo. Mantenga la tcnica primaria misin en mente. Asegrese de que est utilizando la herencia para minimizar la complejidad . Prefiero herencia extensa comprobacin de tipos

Repiten con frecuencia de casos declaraciones a veces sugieren que la herencia podra ser una mejor eleccin de diseo, aunque esto no siempre es cierto. Este es un ejemplo clsico de cdigo que clama por un enfoque ms orientado a objetos: C + + Ejemplo de declaracin de casos que probablemente debera ser reemplazado por herencia interruptor (shape.type) { caso Shape_Circle: shape.DrawCircle (); break; caso Shape_Square: shape.DrawSquare (); break; ... } En este ejemplo, las llamadas a shape.DrawCircle () y shape.DrawSquare () debera ser reemplazado por una nica rutina llamada shape.Draw () , que puede ser llamado independientemente de si la forma es un crculo o un cuadrado. Por otro lado, a veces de casos declaraciones se utilizan para separar realmente diferente tipo de objetos o comportamientos. Aqu es un ejemplo de un caso de declaracin de que es apropiada en un programa orientado a objetos: C + + Ejemplo de declaracin de casos que probablemente no debera ser Sustituido por herencia interruptor (ui.Command ()) { caso Command_OpenFile: OpenFile (); break; caso Command_Print: Imprimir (); break; caso Command_Save: Save (); break; caso Command_Exit: Shutdown (); break; ... } En este caso, sera posible crear una clase base con las clases derivadas y un polimrfica DoCommand () de rutina para cada comando. Pero el significado de DoCommand () sera tan diluido como para tener sentido, y el caso de la declaracin es la solucin ms comprensible. Evite el uso de los datos protegidos de una clase base en una clase derivada (o hacer que datos privados en lugar de proteger, en primer lugar) Como Joshua Bloch dice, "Herencia rompe la encapsulacin" (2001). Cuando heredan de un objeto, se obtiene un acceso privilegiado a ese objeto est protegido rutinas y datos. Si la clase derivada realmente necesita tener acceso a la clase de base de atributos, proporcionan funciones de acceso protegidas en su lugar.

Herencia mltiple La herencia es una herramienta elctrica. Es como usar una motosierra para cortar un rbol en su lugar de una sierra de corte transversal manual. Puede ser muy til cuando se usa con cuidado, pero es peligroso en manos de alguien que no cumpla con las precauciones adecuadas. Si la herencia es una sierra de cadena, la herencia mltiple es una cadena de 1950 de la era visto con sin protector de la hoja, no apagado automtico, y un motor meticuloso. Hay veces cuando es indispensable una herramienta de este tipo, en su mayora, es mejor salir de la herramienta en el garaje donde no pueda hacer dao. Aunque algunos expertos recomiendan el uso amplio de la herencia mltiple (Meyer 1997), en mi experiencia, la herencia mltiple es til principalmente para definir Mixins "," clases simples que se utilizan para aadir un conjunto de propiedades de un objeto. Mixins se llaman mixins porque permiten que las propiedades que se "mezclan" para clases derivadas. Mixins podran ser clases como visualizable , Persistente , Serializable , o se puede ordenar . Mixins son casi siempre abstracta y no estn destinados a ser instanciado independientemente de otros objetos. Mixins requieren el uso de la herencia mltiple, pero no estn sujetos a la problema clsico de diamante herencia asociado con herencia mltiple, siempre como todos los mixins son verdaderamente independiente el uno del otro. Tambin hacen el diseo ms comprensible por "fragmentacin" atributos juntos. Un programador El hecho indiscutible Acerca de los distintos herencia en C + + es que se abre un Pandora cuadro de complejidades que simplemente no existen bajo herencia simple. -Scott Meyers tener una comprensin ms fcil que un objeto utiliza la mixins visualizable y Persistente que entender que un objeto utiliza las 11 rutinas ms especficas que de otro modo sera necesario para poner en prctica esas dos propiedades. Java y Visual Basic reconocen el valor de mixins al permitir que mltiples herencia de interfaces, pero slo la herencia simple de clases. C + + soporta mltiples herencia de los dos interfaz y la implementacin. Los programadores deben utilizar herencia mltiple slo despus de considerar cuidadosamente las alternativas y pesar el impacto sobre la complejidad del sistema y la comprensin. Por qu hay tantas reglas de la herencia? Esta seccin ha presentado numerosas reglas para no meterse en problemas con herencia. El mensaje subyacente de todas estas normas es que, la herencia tiende para trabajar contra el imperativo tcnico primario tiene como programador, que es la de gestionar la complejidad. En aras de la complejidad de control que debe mantener un fuerte sesgo contra la herencia. He aqu un resumen de cundo utilizar la herencia y cundo utilizar la contencin: Si hay varias clases comparten datos comunes, pero no el comportamiento, a continuacin, crear una objetivo comn de que las clases pueden contener. Si hay varias clases de acciones de comportamiento comn, pero no los datos, y luego ellos derivan de una clase base comn que define las rutinas comunes.

 Si hay varias clases de compartir datos y comportamientos comunes, entonces heredar de una clase base comn que define los datos y rutinas comunes. Heredar si desea que la clase base para el control de la interfaz, contener cuando desea controlar su interfaz. Funciones miembro y Datos Aqu hay algunas pautas para la implementacin de las funciones de miembro y datos de miembros efectivamente. Mantener el nmero de rutinas en una clase tan pequeo como sea posible Un estudio de los programas en C + + encontr que un mayor nmero de rutinas por clase fueron asociado con mayores tasas de falla (Basili, Briand y Melo 1996). Sin embargo, No se encontraron otros factores que compiten para ser ms importantes, incluyendo profunda rboles de herencia, gran nmero de rutinas llamadas por una rutina, y fuertes acoplamiento entre las clases. Evaluar el equilibrio entre la reduccin del nmero de las rutinas y estos otros factores. PUNTO CLAVE Referencia cruzada Para ms en la complejidad, vase "Software de Primaria Imperativo tcnico: Gestin de la Complejidad "en No permitir funciones y operadores miembro generados implcitamente que no lo hacen querer A veces usted encontrar que usted desea no permitir ciertas funciones, tal vez desea asignacin no permitir, o si no desea permitir que un objeto sea construida. Se podra pensar que, dado que el compilador genera los operadores automticamente, le pegan permitir el acceso. Pero en tales casos se puede rechazar los utiliza al declarar el constructor, operador de asignacin u otra funcin o operador privado , lo que evitar que los clientes tengan acceso a ella. (Hacer el constructor privado es una tcnica estndar para la definicin de una clase singleton, el cual se discute ms adelante en este captulo.) Minimizar las llamadas de rutina directos a otras clases Un estudio encontr que el nmero de fallos en una clase se correlacion estadsticamente con el nmero total de rutinas que fueron llamados desde dentro de una clase (Basili, Briand, y Melo 1996). El mismo estudio encontr que mientras ms clases a la clase utilizar, mayor es su tasa de fallo tiende a ser. Minimizar las llamadas de rutina indirectos a otras clases Conexiones directas son bastante peligrosos. Indirectos conexiones-tales como account.ContactPerson (). DaytimeContactInfo (). Fax: () -tienden a ser an ms peligrosos. Los investigadores han formulado una regla llamada la "Ley de Demeter "(Lieberherr y Holanda, 1989), que bsicamente establece que un objeto puede llamar a cualquiera de sus propias rutinas. Si Object Una instancia a un objeto B, puede llamar al cualquiera de las rutinas de objeto B. Pero hay que evitar llamar a las rutinas en los objetos proporcionada por objeto B. En la cuenta de ejemplo anterior, lo que significa account.ContactPerson () est bien, pero account.ContactPerson (). DaytimeContactInfo () no lo es.

Esta es una explicacin simplificada, y, dependiendo de cmo estn dispuestas las clases, se podra ser aceptable para ver una expresin como account.ContactPerson (). DaytimeContactInfo () . Vea los recursos adicionales Al final de este captulo para obtener ms detalles. En general, reducir al mnimo el grado en que una clase colabora con otra clases Trate de minimizar todo lo siguiente: El nmero de tipos de objetos instanciados Nmero de rutina directo distinto pide a los objetos instanciados Nmero de llamadas de rutina de los objetos devueltos por otros objetos instanciados Constructores Aqu hay algunas pautas que se aplican especficamente a los constructores. Directrices para constructores son bastante similares en todos los idiomas (C + +, Java y Visual Basic, de todos modos). Destructores varan ms, y por lo que debe revisar los materiales relacionados en la seccin "Recursos adicionales" al final de este captulo para ms informacin sobre destructores. Inicialice todos los datos de los miembros de todos los constructores, a ser posible Inicializar todos los miembros de datos de todos los constructores es una defensa econmica prctica de programacin. Inicializar miembros de datos en el orden en que estn declarados Dependiendo de su compilador, puede experimentar algunos errores squirrelly por intentar inicializar miembros de datos en un orden distinto al orden en el que estn declaradas. Utilizando el mismo orden en ambos lugares tambin proporciona consistencia que hace que el cdigo sea ms fcil de leer. Hacer cumplir la propiedad singleton mediante un constructor privado Si desea definir una clase que permite que slo un objeto a una instancia, que puede cumplir esta ocultando todos los constructores de la clase y, a continuacin proporciona una esttica getInstance () para acceder a la rutina sola instancia de la clase. He aqu un ejemplo de cmo funcionara: Java Ejemplo de Aplicacin de un Singleton con un constructor privado public class maxid { / / Constructores y destructores maxid privada () { ... } ... / / Rutinas pblicas public static maxid GetInstance () { volver m_instance; } ... / / Miembros privados privado static final maxid m_instance maxid = new (); ...

} El constructor privado slo se llama cuando el objeto esttico m_instance es inicializado. En este enfoque, si desea hacer referencia a la maxid singleton, que que simplemente se refieren a MaxId.GetInstance () . Hacer cumplir la propiedad singleton utilizando todos los datos de los miembros estticos y recuento de referencias Un medio alternativo de hacer cumplir la propiedad singleton es declarar todo el Los datos de clase estticos. Puede determinar si la clase est siendo utilizado por incrementar un contador de referencia en el constructor del objeto y decreciendo en el destructor (C + +) o Terminar rutina (Java y Visual Basic). El mtodo de recuento de referencias llega con algunas dificultades sistmicas. Si el referencia se copia, el miembro de datos de clase no ser necesariamente incrementa, lo que puede conducir a un error en el recuento de referencias. Si este enfoque es utilizado, el equipo del proyecto debe estandarizarse en las convenciones de usar de referencia objetos contados de forma coherente. Prefiero copias en profundidad a las copias de poca profundidad hasta que se demuestre lo contrario Una de las decisiones ms importantes que va a hacer sobre los objetos complejos es la posibilidad de implementar copias en profundidad o copia superficial del objeto. Una copia completa de un objeto es miembro de una copia a bit de datos de los miembros del objeto. Una copia superficial normalmente simplemente apunta a o se refiere a una sola copia de referencia. Copias en profundidad son ms fciles de codificar y mantener que las copias de poca profundidad. Adems de el cdigo de uno u otro tipo de objeto contendran copias superficiales aadir cdigo a contar referencias, asegrese de copias de seguridad de objetos, comparaciones seguras, elimina seguros, etc. Este cdigo tiende a ser propenso a errores, y debe evitarse a menos que haya una razn de peso para crearlo. La motivacin para la creacin de copias de poca profundidad es generalmente para mejorar el rendimiento. A pesar de la creacin de mltiples copias de objetos de gran tamao puede ser estticamente ofensivo, que rara vez causa ningn impacto en el rendimiento medible. Un pequeo nmero de objetos pueden causar problemas de rendimiento, pero los programadores son notoriamente pobres en adivinar qu cdigo realmente causa problemas. (Para ms detalles, vase el captulo 25.) Porque es una mala compensacin para agregar complejidad para un rendimiento dudoso ganancias, un buen mtodo para copias en profundidad vs superficial es a preferir copias en profundidad hasta se demuestre lo contrario. Si usted encuentra que usted no tiene que utilizar un enfoque poco profundas copia, Scott Meyers ' Ms eficaz C + + , punto 29 (1996) contiene un excelente anlisis de las cuestiones en C + +. De Martin Fowler Refactoring (1999) describe los pasos especficos necesaria para convertir de copias de copias en profundidad de poca profundidad y de copias en profundidad de copias de poca profundidad. (Fowler ellos hacen referencia a objetos y los objetos de valor requiere.) 6.4 Razones para crear una clase Si usted cree todo lo que lee, es posible que la idea de que la nica razn para

crear una clase es para modelar objetos del mundo real. En la prctica, se crean clases de muchas razones ms que eso. Aqu hay una lista de buenas razones para crear una clase. Modelo objetos del mundo real Modelado de objetos del mundo real podra no ser la nica razn para crear una clase, pero sigue siendo una buena razn! Crear una clase para cada objeto del mundo real que su modelos de programas. Poner los datos necesarios para el objeto en la clase y, a continuacin, crear rutinas de servicio que el modelo de comportamiento del objeto. Vase la discusin de ADT en la Seccin 6.1 para ejemplos. Objetos abstractos Modelo Otra buena razn para crear una clase es modelar un objeto abstracto -un objeto eso no es un objeto concreto, en el mundo real, sino que proporciona una abstraccin de otra objetos concretos. Un buen ejemplo es la clsica forma de objeto. Circle y Square existe realmente, pero la forma es una abstraccin de otras formas especficas. En proyectos de programacin, las abstracciones no estn listos hizo como Shape es, as que tenemos que trabajar ms duro para llegar a abstracciones limpias. El proceso de destilar conceptos abstractos de las entidades del mundo real no es determinista, y diferentes diseadores se resumen a cabo diferentes generalidades. Si no supiramos acerca de las formas geomtricas como crculos, cuadrados y tringulos, por ejemplo, podramos llegar a formas ms inusuales como forma de calabaza, forma colinabo y Pontiac Aztek forma. El subir con objetos abstractos apropiadas es uno de los principales retos en el diseo orientado a objetos. Reducir la complejidad La razn ms importante para crear una clase es reducir un programa de complejidad. Crear una clase para ocultar la informacin de modo que usted no tendr que pensar respecto. Claro, usted tendr que pensar en ello al escribir la clase. Pero despus de est escrito, usted debera ser capaz de olvidar los detalles y el uso de la clase sin conocimiento de su funcionamiento interno. Otras razones para crear clases de minimizacin tamao del cdigo, mejorando el mantenimiento, y mejorar tambin la correccin-son buenos razones, pero sin el poder de abstraccin de clases, programas complejos hara imposible para gestionar intelectualmente. Aislar la complejidad La complejidad en todos los algoritmos de formas complicadas, conjuntos de datos grandes y complejos protocolos de comunicaciones, y as sucesivamente-es propensa a errores. Si se produce un error, ser ms fcil de encontrar si no se transmite a travs del cdigo, pero se localiza dentro de un clase. Los cambios derivados de corregir el error no afectar a otro cdigo, ya que slo una clase tendr que ser-otra fija cdigo no ser tocado. Si usted encuentra un Referencia cruzada La razones para crear una clase solaparse con las razones a crear rutinas. Para obtener ms informacin, consulte la Seccin 7.1, "Vlido Razones para crear un Rutina ". Referencia cruzada Para ms en la identificacin de bienes- los objetos del mundo, consulte "Encontrar Los objetos del mundo real "en Seccin 5.3. PUNTO CLAVE algoritmo mejor, ms simple, o ms fiable, que ser ms fcil para reemplazar la antigua algoritmo de si ha sido aislado en una clase. Durante el desarrollo, ser ms fcil de probar varios diseos y mantener el que mejor funciona.

Ocultar detalles de implementacin El deseo de ocultar los detalles de implementacin es una razn maravillosa para crear una clase si los datos son tan complicadas como una base de datos de acceso complicado o tan mundanos como si un miembro de datos especfico se almacena como un nmero o una cadena. Limitar los efectos de los cambios Aislar las reas que son propensos a cambiar de manera que los efectos de los cambios se limitan a el alcance de una sola clase o, a lo sumo, algunas clases. Diseo de modo que las reas que son ms probable que cambie son los ms fciles de cambiar. reas susceptibles de cambiar incluyen dependencias de hardware, entrada / salida, tipos de datos complejos y reglas de negocio. La subseccin titulada "Ocultar secretos (ocultamiento de informacin)" en la Seccin 5.3 descrito varias fuentes comunes de cambio. Algunos de los ms comunes son resumen en esta seccin. Ocultar datos globales Si necesita utilizar los datos globales, se pueden ocultar los detalles de implementacin detrs de una interfaz de clase. Trabajar con datos globales a travs de rutinas de acceso proporciona varias ventajas en comparacin con el trabajo con datos globales directamente. Usted puede cambiar la estructura de los datos sin cambiar el programa. Usted puede monitorear accede a los datos. La disciplina de la utilizacin de rutinas de acceso tambin le anima pensar si los datos son realmente globales, sino que a menudo se hace evidente que los "datos globales" es realmente slo datos de la clase. Agilizar el paso de parmetros Si ests pasando un parmetro entre varias rutinas, que podran indicar la necesidad para factorizar las rutinas en una clase que comparten el parmetro segn datos de la clase. Racionalizacin de paso de parmetros no es un objetivo per se, sino que pasa gran cantidad de datos todo indica que una organizacin de clase diferente podra funcionar mejor. Hacer los puntos centrales de control Es una buena idea para controlar cada tarea en un solo lugar. Control asume muchas formas. El conocimiento de la cantidad de entradas en una tabla es una forma. Control de los dispositivos- archivos, conexiones de base de datos, impresoras, etctera-es otra. Uso de una clase a leer y escribir en una base de datos es una forma de control centralizado. Si la base de datos debe convertirse en un archivo plano o datos en memoria, los cambios afectarn slo la una clase. La idea de un control centralizado es similar a la ocultacin de informacin, pero tiene singular poder heurstico que hace que valga la pena aadir a su caja de herramientas de programacin. Referencia cruzada Para una discusin de los problemas asociado con el uso mundial datos, consulte la Seccin 13.3, "Datos globales". Referencia cruzada Para detalles de la ocultacin de informacin, consulte "Ocultar Secretos (Informacin ocultar) "en Seccin 5.3. Facilitar cdigo reutilizable Cdigo puesto en clases bien factorizados se puede reutilizar en otros programas con ms facilidad que el mismo cdigo incrustado en una clase ms grande. Incluso si una

seccin de cdigo es llamado desde un solo lugar en el programa y es comprensible como parte de un clase ms grande, tiene sentido ponerlo en su propia clase si ese trozo de cdigo podra ser utilizado en otro programa. Laboratorio de Ingeniera de Software de la NASA estudiaron diez proyectos que persiguen reutilizar agresivamente (McGarry, Waligora, y McDermott 1989). En tanto el enfoques orientados a objetos y la orientacin funcional, los proyectos iniciales no fueron capaces de tomar la mayor parte de su cdigo de proyectos anteriores ya anterior proyectos no haban establecido una base de cdigo suficiente. Posteriormente, los proyectos que diseo funcional utilizada fueron capaces de tomar el 35 por ciento de su cdigo de proyectos anteriores. Los proyectos que utilizan un enfoque orientado a objetos pudieron tener ms de 70 por ciento de su cdigo de proyectos anteriores. Si usted puede evitar escrito el 70 por ciento de su cdigo por planificar el futuro, hazlo! Cabe destacar que el ncleo del enfoque de la NASA para crear clases reutilizables no implican "el diseo para su reutilizacin." NASA identifica candidatos reutilizacin en los extremos de sus proyectos. A continuacin, realizar el trabajo necesario para hacer que las clases reutilizables como un proyecto especial al final del proyecto principal o como el primer paso en un nuevo proyecto. Este enfoque ayuda a prevenir la "sobrerregulacin"-creacin de la funcionalidad que no es necesario y que agrega complejidad innecesaria. Plan de una familia de programas Si usted espera que un programa que se desea modificar, que es una buena idea para aislar las partes que esperas para cambiar al ponerlos en sus propias clases. A continuacin, puede modificar las clases sin afectar al resto del programa, o puede poner en clases completamente nuevas en su lugar. Pensar a travs no slo de lo que se programa parecen, pero lo que toda la familia de programas podra ser como una poderosa heurstica para anticipar todas las categoras de cambios (Parnas 1976). Hace varios aos me las arregl un equipo que escribi una serie de programas utilizados por nuestros clientes para vender seguros. Tuvimos que adaptar cada programa al cliente del especfico las tasas de seguros, el formato quote-informe, y as sucesivamente. Sin embargo, muchas partes de los programas eran similares: las clases que introducir informacin sobre los clientes potenciales, que informacin almacenada en una base de datos de clientes, que levant las tasas, que computarizada las tasas totales de un grupo, y as sucesivamente. El equipo de tenerse el programa para que cada parte que vara de cliente a cliente estaba en su propia clase. La inicial programacin podra haber tardado tres meses ms o menos, pero cuando nos dieron una nueva cliente, simplemente escribimos un puado de nuevas clases para el nuevo cliente y nos dej que en el resto del cdigo. A los pocos das de trabajo, y voil! Software de encargo! DATOS DUROS Referencia cruzada Para ms en la aplicacin de la cantidad mnima de funcionalidad requerida, vase "A programa de cdigo que contiene parece que podra ser necesario algn da "en la Seccin 24.3. Paquete operaciones relacionadas En los casos en que no se puede ocultar la informacin, compartir datos, o un plan para la flexibilidad, todava se puede empaquetar conjuntos de operaciones en grupos sensibles como trig funciones, funciones estadsticas, rutinas de manipulacin de cadenas, de manipulacin de bits rutinas, rutinas de grficos, y as sucesivamente. Para lograr una refactorizacin especfica 1193

Muchas de las refactorizaciones especficos descritos en el captulo 24 dan lugar a nuevas clases-incluyendo la conversin de una clase o dos, ocultando un delegado, la eliminacin de un medio hombre, y la introduccin de una clase de extensin. Estas nuevas clases podran estar motivados por el deseo de lograr una mejor ninguno de los objetivos descritos en este seccin. Las clases que se deben evitar Mientras que las clases en general son buenas, se puede ejecutar en pocas trampas. stos son algunas clases para evitar. Evitar la creacin de clases de dios Evitar la creacin de clases omniscientes que todo lo sabe y todo lo puede. Si un clase pasa su tiempo recuperar los datos de otras clases con get () y set () rutinas (es decir, cavar en sus negocios y decirles qu hacer), pregunte si esa funcionalidad podra estar mejor organizada en las otras clases en lugar de a la clase dios (Riel 1996). Eliminar las clases irrelevantes Si una clase se compone slo de datos, pero no el comportamiento, pregntese si en realidad es un clase y considerar degradarlo para convertirse en un atributo de otra clase. Evite las clases con nombres de los verbos Una clase que tiene slo el comportamiento pero no hay datos por lo general no es realmente una clase. Considere la posibilidad de convertir una clase como DatabaseInitialization () o StringBuilder () en un de rutina en alguna otra clase. Resumen de las razones para crear una clase Aqu hay una lista resumida de las razones vlidas para crear una clase: Modelo de objetos del mundo real Modelo de objetos abstractos Reducir la complejidad Aislar complejidad Ocultar detalles de implementacin Referencia cruzada Este tipo de clase se suele llamar una estructura. Para ms informacin sobre estructuras, vase la seccin 13.1, "Estructuras". Limite los efectos de los cambios Ocultar datos globales Optimizar el paso de parmetros Asegrese de los puntos centrales de control de Facilitar cdigo reutilizable Plan de una familia de programas operaciones vinculadas del paquete Para realizar una refactorizacin especfica 6.5 Cuestiones especficas del idioma Aproximaciones a clases en diferentes lenguajes de programacin varan en interesante maneras. Considere cmo reemplazar una rutina miembro para conseguir el polimorfismo en una clase derivada. En Java, todas las rutinas son reemplazables por defecto, y una rutina debe ser declarada definitiva para evitar una clase derivada la reemplace. En C + +, rutinas no son reemplazables por defecto. Una rutina debe declararse virtuales en el clase base para ser reemplazable. En Visual Basic, la rutina

debe ser declarada reemplazable en la clase base y la clase derivada debe utilizar las anulaciones palabra clave. Estas son algunas de las reas relacionadas con la clase que varan significativamente dependiendo de la idioma: Comportamiento de los constructores invalidados y destructores en un rbol de herencia Comportamiento de los constructores y destructores bajo control de excepciones Condiciones Importancia de los constructores predeterminados (constructores sin argumentos) Hora en la que se llama a un destructor o finalizador La sabidura de anular los operadores integrados en el lenguaje, incluyendo misiones y la igualdad Cmo se maneja la memoria como los objetos son creados y destruidos, o que sean declarada y salir del alcance Discusiones detalladas de estos problemas estn ms all del alcance de este libro, pero el Seccin "Recursos adicionales" al final de este captulo puntos para una buena recursos especficos del idioma. 6.6 Ms all de las clases: Paquetes Las clases son actualmente la mejor manera para que los programadores para lograr la modularidad. Pero modularidad es un gran tema, y se extiende ms all de las clases. En los ltimos dcadas, el desarrollo de software ha avanzado en gran parte por el aumento de la granularidad de las agregaciones que tenemos que trabajar. La primera agregacin que tuvimos fue la declaracin, que en ese momento pareca un gran paso de instrucciones de la mquina. Luego vinieron las subrutinas, y ms tarde vinieron las clases. Es evidente que podramos apoyar mejor los objetivos de la abstraccin y la encapsulacin si tuviramos buenas herramientas para la agregacin de grupos de objetos. Ada apoyado la nocin de paquetes hace ms de una dcada, y soporta Java paquetes hoy. C + + 's y C #' s espacios de nombres son un buen paso en la direccin correcta, aunque la creacin de paquetes con ellos es un poco como la creacin de pginas web directamente en html. Si est programando en un idioma que no es compatible con los paquetes directamente, puede crear su propia versin de la pobre-programador de un paquete y hacerlo cumplir a travs de normas de programacin que incluyen convenciones de nombres que diferencian las clases que son pblicos y que son para el uso privado del paquete convenciones de nomenclatura, convenciones de cdigo de organizacin (estructura del proyecto), o tanto que identifican a qu paquete pertenece a cada clase Reglas que definen qu se permiten envases de usar que otros paquetes, incluyendo si el uso puede ser la herencia, la contencin, o ambos Estos solucin son buenos ejemplos de la diferencia entre la programacin en un lenguaje de programacin vs en un idioma. Para ms informacin sobre esta distincin, vase Seccin 34.4, "programa en su idioma, no en l." Referencia cruzada Esta es una lista de consideraciones sobre la calidad de la clase. Para una lista de los pasos que se utilizan para construir una clase, ver la lista de comprobacin "La programacin Pseudocdigo Proceso "en el Captulo 9, pgina 000. Tipos abstractos de datos

Has pensado en las clases en su programa como tipos abstractos de datos y evaluado sus interfaces desde ese punto de vista? Referencia cruzada Para ms en la distincin entre las clases y paquetes, consulte "Niveles de Diseo "en la Seccin 5.2. CC2E.COM/0672 Abstraccin La clase tiene un propsito central? La clase bien nombrado, y que su nombre describe su propsito central? La interfaz de la clase presenta una abstraccin consistente? La interfaz de la clase hace evidente cmo se debe utilizar la clase? Es interfaz abstracta de la clase suficiente como para que usted no tiene que pensar en cmo se implementan sus servicios? Se puede tratar la clase como un cuadro negro? Los servicios de la clase completar suficiente que otras clases no tienen que entrometerse en su informacin interna? Tiene informacin relacionada han quitado de la clase? Ha pensado en la subdivisin de la clase en las clases de componentes, y ha subdividido tanto como sea posible? Est la preservacin de la integridad de la interfaz de la clase cuando se modifica la clase? Encapsulacin La clase de minimizar la accesibilidad a sus miembros? Evita la clase de exposicin de datos de los miembros? La clase de ocultar sus detalles de implementacin de otras clases tanto como los permisos de lenguaje de programacin? Evita la clase de hacer suposiciones sobre sus usuarios, incluyendo su clases derivadas? Es la clase independiente de las otras clases? Es dbilmente acoplados? Herencia Es la herencia utilizado slo para modelo "es un" relaciones? La documentacin de la clase describir la estrategia de la herencia? Hacer clases derivadas se adhieren al principio de sustitucin Liskov? No clases derivadas evitar "primordiales" rutinas no reemplazables? Son interfaces comunes, datos, y el comportamiento lo ms alto posible en el rbol de herencia? Son rboles de herencia bastante superficial? Todos los miembros de datos de la clase base privada en lugar de proteger? Otras cuestiones de aplicacin Contiene la clase sobre siete miembros de datos o menos? La clase de minimizar las llamadas de rutina directos e indirectos a otras clases? Colabora la clase con otras clases en la medida absolutamente necesario? Se inicializan todos los datos de los miembros en el constructor? Es la clase diseado para ser utilizado como copias en profundidad en lugar de copias poco profundas a menos que haya una razn de medicin para crear copias superficiales? Cuestiones especficas del idioma Ha investigado los problemas especficos del idioma para las clases en su lenguaje de programacin especfico? Recursos adicionales Las clases en general

Meyer, Bertrand. Construccin de Software Orientado a Objetos, 2 ed . Nueva York: Prentice Hall PTR, 1997. Este libro contiene una discusin a fondo de Abstract Tipos de datos y explica cmo se forman la base para las clases. Captulos 14-16 discutir herencia en profundidad. Meyer proporciona un fuerte argumento a favor de la herencia mltiple en el captulo 15. Riel, Arthur J. Heurstica diseo orientado a objetos , Reading, Mass.: Addison Wesley, 1996. Este libro contiene numerosas sugerencias para mejorar el programa diseo, sobre todo en el nivel de clase. Evit el libro durante varios aos, ya que pareca ser demasiado grande (hablar de la gente en casas de cristal!). Sin embargo, el cuerpo de el libro es slo alrededor de 200 pginas. La escritura de Riel es accesible y agradable. El contenido se centra y prctico. C++ Meyers, Scott. Efectiva C + +: 50 maneras especficas de mejorar sus programas y Diseos, 2 Ed. , Reading, Mass.: Addison Wesley, 1998. Meyers, Scott, 1996, ms eficaz C + +: 35 Nuevas formas de mejorar su Programas y modelos , Reading, Mass.: Addison Wesley, 1996. Ambos Libros Meyers referencias cannicas para programadores de C + +. Los libros son entretener y ayudar a inculcar la apreciacin de un idioma-abogado de los matices de C + +. Java Bloch, Joshua. Efectiva Java Programming Language Guide , Boston, Mass.: Addison Wesley, 2001. El libro de Bloch ofrece muchos buenos consejos Java especfica as como la introduccin de buenas prcticas ms generales, orientados a objetos. CC2E.COM/0679 CC2E.COM/0686 CC2E.COM/0693 Visual Basic Los siguientes libros son buenas referencias de clases en Visual Basic: Foxall, James. Normas prcticas para Microsoft Visual Basic. NET , Redmond, WA: Microsoft Press, 2003. . Cornell, Gary y Jonathan Morrison . Programacin VB NET: Gua para Los programadores con experiencia , Berkeley, California: Apress, 2002. Barwell, Fred, et al. Profesional VB.NET, 2 ed. , Wrox, 2002. Puntos clave interfaces de clase deben proporcionar una abstraccin consistente. Muchos de los problemas surgir de violar este principio nico. Una interfaz de clase debe ocultar-a algo interfaz del sistema, un diseo decisin, o un detalle de implementacin. La contencin es generalmente preferible a la herencia a menos que usted est modelando una "Es una" relacin. La herencia es una herramienta til, pero aade complejidad, lo que es contrario a la Imperativo tcnico primario de minimizar la complejidad. Las clases son su principal herramienta para la gestin de la complejidad. D su diseo como toda la atencin necesaria para lograr ese objetivo.