Me gustaría mantener este breve. Construyo un HouseA que tiene dos salas, digamos BedRoom y StudyRoom, ambas derivadas de una clase base llamada Room. BedRoom y StudyRoom tienen un mismo elemento primario llamado House. Además, cualquier habitación de una casa puede acceder a otras habitaciones solo a través del padre. Si BedRoom tiene que acceder a cualquier atributo de StudyRoom, debe ir solo a través de House (es decir, principal) y viceversa.¿Debo usar herencia o composición?
HouseA ISA House
HouseA HAS BedRoom and StudyRoom.
BedRoom ISA Room
StudyRoom ISA Room
Ahora el problema: Digamos, voy a construir otra casa (por ejemplo HouseB), que es un exactamente el mismo que el anterior, pero con un cambio. No quiero dos habitaciones separadas (es decir, BedRoom y StudyRoom), sino una habitación individual (MasterRoom) que tiene ambas instalaciones. En aras de la reutilización de código, lo que podía pensar de las siguientes opciones de diseño:
Option-1:
HouseB ISA House
HouseB HAS MasterRoom
MasterRoom ISA Room
Aquí pierdo la capacidad de reutilizar los atributos de BedRoom y StudyRoom que creé para HouseA. Tenga en cuenta que la mayoría de los atributos de BedRoom y StudyRoom deben volverse a implementar en MasterRoom de todos modos, lo que da como resultado la duplicación del código.
Option-2:
HouseB ISA House
HouseB HAS MasterRoom
MasterRoom ISA Room
MasterRoom HAS LogicalBedroom
MasterRoom HAS LogicalStudyRoom
LogicalBedroom ISA BedRoom
LogicalStudyRoom ISA StudyRoom
De esta manera, puedo usar la composición para que pudiera volver a utilizar la mayor parte de mi código (tengo varios miles de líneas de código que podría volver a utilizar), pero el problema es que BedRoom es una clase concreta y logicalBedRoom halle ciertos atributos no son adecuados y pueden verse obligados a anular los métodos para que no hagan nada. Por ejemplo, Bedroom->noOfSides() = 4 y logicalBedRoom->noOfSides() = ??. ¿Es esto un buen uso de la herencia?
Mi diseño real es para un chip complejo que combina la funcionalidad de dos chips individuales (utilicé la analogía de House (motherboard) y Room (chip)). Codigo en Object Oriented Perl y realmente apreciaría cualquier sugerencia de diseño alternativa.
Gracias
¿Es el mismo papel que Mixin en Ruby? – rpattabi
@ ragu.pattabi, los roles son similares a mixins. La principal diferencia es que los roles tienen algunos controles sobre cuándo se pueden aplicar: los roles pueden requerir que ciertos métodos estén disponibles en una clase consumidora. Hay otras diferencias, también. Uso de Perl del término mapas de roles para 'rasgos' en el mundo más amplio de la investigación OO. En Perl/Moose, un rasgo es un rol aplicado a un método que utiliza el protocolo metaobjeto, que está más allá del alcance de esta respuesta. Planteo el punto para poder evitar la apariencia de no-sequitor mientras lo dirijo a un recurso sobre rasgos en general: http://scg.unibe.ch/research/traits/ – daotoad
Eso significa que los roles proporcionan un mecanismo como el método de la plantilla patrón sin el equipaje de la herencia. Eso es bastante interesante. – rpattabi