Cartera A -> Fondo 1"Es un" vs "Tiene un": ¿cuál es mejor?
Cartera A -> Fondo 2
Cartera A -> Fondo 3
no podía enmarcar mi frase sin usar no está/ha. Pero entre 1 & 2,
1) tiene un:
class PortfolioA
{
List<Fund> obj;
}
2) es una:
class PortfolioA : List<Fund>
{
}
cuál cree usted que es mejor desde el punto de extensibilidad, facilidad de uso? Todavía puedo acceder a mis fondos de cualquier manera, aunque con un pequeño cambio sintáctico.
Voto con las otras personas que dicen que HAS-A es mejor en este caso. Usted pregunta en un comentario:
cuando digo que una Cartera es sólo una colección de fondos, con algunas atributos propios como TotalPortfolio etc, hace que fundamentalmente se convierta en una "ES-UN "¿?"
No lo creo. Si dices Portfolio IS-A List<Fund>, ¿qué ocurre con otras propiedades de la Cartera? Por supuesto, puede agregar propiedades a esta clase, pero ¿es correcto modelar esas propiedades como propiedades de la lista? Porque eso es básicamente lo que estás haciendo.
¿Qué sucede si se requiere una cartera para admitir más de un List<Fund>? Por ejemplo, puede tener una lista que muestre el saldo actual de las inversiones, pero otra lista que muestre cómo se invierten las nuevas contribuciones. ¿Y qué sucede cuando se suspenden los fondos y se utiliza un nuevo conjunto de fondos para sucederlos? La información histórica es útil para rastrear, así como la asignación de fondos actual.
El punto es que todas estas propiedades no son propiedades correctas de una Lista, aunque pueden ser propiedades de la Cartera.
¡Absolutamente! Podrías justificar aún más: incluso la humilde 'Lista' tiene propiedades adicionales (por ejemplo, longitud) que no tienen nada que ver con * uno * de los elementos. Por lo tanto, 'List
El primero, porque debes intentar favorecer la composición por encima de la herencia cuando puedas.
¿Puede justificar esa afirmación? – Blorgbeard
No lo expresaría de esa manera. –
Tiene razón, siempre que puede. Quizás no siempre, pero es casi siempre preferible a menos que sea obvio. Google "Extiende es malo" para más información. –
Iría con la opción (1) - composición, ya que eventualmente podría tener atributos específicos de la cartera, en lugar de los fondos.
El primero, porque es "consiste en". => Composición
no 'siempre' favorece la composición o la herencia o viceversa; ellos tienen diferentes semánticas (significados); mira cuidadosamente los significados, luego decide: no importa si uno es "más fácil" que el otro, para la longevidad es importante que obtienes la semántica correcta
recuerda: is-a = tipo, has-a = contención
por lo que en este caso, una cartera lógicamente es una colección de fondos; una cartera en sí es no es un tipo de fondo, por lo que la composición es la relación correcta
EDIT: He leído mal la pregunta originalmente, pero la respuesta sigue siendo la misma. Una Cartera no es un tipo de lista, es una entidad distinta con sus propias propiedades. Por ejemplo, una cartera es un agregado de instrumentos financieros con un costo de inversión inicial, un valor actual total, un historial de valores a lo largo del tiempo, etc., mientras que una Lista es una colección simple de objetos. Una cartera es un "tipo de lista" solo en el sentido más abstracto.
EDIT 2: piense en la definición de cartera: es, sin excepción, caracterizada como una colección de cosas. La cartera de un artista es una colección de sus obras de arte, la cartera de un diseñador web es una colección de sus sitios web, la cartera de un inversor consta de todos los instrumentos financieros que poseen, y así sucesivamente. Entonces, claramente, necesitamos una lista (o algún tipo) para representar una cartera, ¡pero eso de ninguna manera implica que una cartera sea un tipo de lista!
supongamos que decidimos dejar que Portfolio herede de List. Esto funciona hasta que agreguemos Stock, Bond o Metal precioso a la Cartera, y de repente, la herencia incorrecta ya no funciona. O supongamos que se nos pide que modelemos, digamos, la cartera de Bill Gates, y descubramos que la Lista se quedará sin memoria ;-) Más realistamente, después de la refactorización futura probablemente descubriremos que deberíamos heredar de una clase base como Asset, pero si ya hemos heredado de List, entonces no podemos.
Resumen: distingue entre las estructuras de datos que elegimos para representar un concepto y la semántica (tipo de jerarquía) del concepto en sí.
Correcto, si Portfolio hubiera sido un tipo de fondo, es-a hubiera tenido sentido. Aquí, cartera es una lista de fondos, con un conjunto de propiedades que se aplican a todos los fondos. Todavía no veo cómo no se puede llamar como un is-a. ¿O es solo cómo enmarcas tu oración en este caso? – aliensurfer
@PrakashR: en realidad leí mal la pregunta y pensé que quería hacer de Portfolio una subclase de Fund ;-) Sería incluso peor hacer de Portfolio una subclase de List, porque List es una colección genérica y una Cartera es una entidad legal. Las carpetas tienen un valor total en el momento t, las listas no, etc. –
Depende si la empresa define una Cartera como un grupo (y solo un grupo) de fondos. Si existe la remota posibilidad de que pueda contener otros objetos, diga "propiedad", luego vaya con la opción 1. Vaya con la opción 2 si existe un vínculo fuerte entre un grupo de fondos y el concepto de Cartera.
En cuanto a la extensibilidad y utilidad 1 tiene la ligera ventaja sobre 2. Realmente no estoy de acuerdo con el concepto de que siempre debe favorecer a uno sobre el otro. Realmente depende de cuáles sean los conceptos reales de la vida real. Recuerde, siempre puede^refactorizar.
^Para la mayoría de los casos de siempre. Si está expuesto públicamente, entonces obviamente no.
Estoy de acuerdo con Rob aquí. Soy dueño de bonos y acciones y de ira, por lo tanto, mi cartera no es una lista de mis fondos. También estoy de acuerdo con el uno sobre el otro. Si es "un", entonces lo es. Si "tiene un" entonces lo hace .. – baash05
Diferiré con lo que parece ser la opinión común. En este caso creo que es una cartera muy poco más que una colección de fondos ... Mediante el uso de la herencia se permite el uso de varios constructores, como en
public Portfolio(CLient client) {};
public Portfolio(Branch branch, bool Active, decimal valueThreshold)
{
// code to populate collection with all active portfolios at the specified branch whose total vlaue exceeds specified threshold
}
y indexadores como en:
public Fund this[int fundId] { get { return this.fundList[fundId]; } }
etc. etc.
si desea poder tratar las variables de tipo Portafolio como una colección de fondos, con la sintaxis asociada, este es el mejor enfoque.
Portfolio BobsPortfolio = new Portfolio(Bob);
foreach (Fund fund in BobsPortfolio)
{
fund.SendStatement();
}
o cosas por el estilo
Me refería a ese tipo de utilidad de accesibilidad. Pero luego, desde una perspectiva purista, un "has-a" parece más apropiado. Acepto una respuesta de arriba. Esencialmente es cómo el negocio (y usted) lo perciben. – aliensurfer
En cierto sentido, las clases de colección son un poco la excepción al enfoque purista para mí, porque, por definición, una colección de cosas "Tiene un" montón de esas cosas en él ... Es la naturaleza misma de una colección ... –
Dibujaría la línea cuando el objeto padre contenga más de una colección de diferentes clases de objetos subordinados ... como si estuviera modelando un equipo deportivo, con una colección interna de Jugadores, y otra colección interna de juegos programados, y otra colección de entrenadores, etc ... –
IS-Un buque relación representa herencias y HAS-Un buque relación representa composición. Para el escenario mencionado anteriormente, preferimos la composición ya que PortfolioA tiene una lista y no es el tipo de lista.Las herencias se utilizan cuando la cartera A es un tipo de lista, pero aquí no. Por lo tanto, para este escenario, deberíamos preferir la Composición.
Consulte también [prefer-composition-over-inheritance?] (Http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance?rq=1) – nawfal