Портфолио A → Фонд 1
Портфолио A → Фонд 2
Портфолио A → Фонд 3
Я не мог записать свое предложение, не используя has/has. Но между 1 и 2,
1) имеет a:
class PortfolioA
{
List<Fund> obj;
}
2) является:
class PortfolioA : List<Fund>
{
}
который, по вашему мнению, лучше с точки зрения расширяемости, удобства использования? Я все равно могу получить доступ к своим средствам в любом случае, хотя и с небольшим синтаксическим изменением.
Я проголосую с другими людьми, которые говорят, что HAS-A лучше в этом случае. Вы спрашиваете в комментарии:
когда я говорю, что портфолио - это просто сбор средств, с несколькими атрибуты, подобные TotalPortfolio и т.д., Делает это в принципе не стать "is-a"?
Я так не думаю. Если вы скажете Portfolio IS-A List<Fund>, как насчет других свойств портфолио? Конечно, вы можете добавлять свойства к этому классу, но правильно ли моделировать эти свойства как свойства List? Потому что это в основном то, что вы делаете.
Также, если для поддержки более одного List<Fund> требуется портфолио? Например, у вас может быть один Список, который показывает текущий баланс инвестиций, а другой список, который показывает, как вкладываются новые вклады. А как насчет того, когда средства прекращены, и для их успеха используется новый набор средств? Историческая информация полезна для отслеживания, а также текущего распределения средств.
Дело в том, что все эти свойства не являются корректными свойствами списка, хотя они могут быть свойствами портфолио.
не всегда "предпочитают композицию или наследование или наоборот"; они имеют разную семантику (значения); внимательно посмотрите на значения, затем решите - не имеет значения, "легче ли", чем другой, для долголетия важно, чтобы вы получили правильность семантики.
запомнить: is-a = type, has-a = сдерживание
поэтому в этом случае портфель логически представляет собой сбор средств; сам портфель не является типом фонда, поэтому композиция является правильной связью
РЕДАКТИРОВАТЬ: я неправильно истолковал вопрос, но ответ все тот же. Портфель не является типом списка, он представляет собой отдельный объект со своими собственными свойствами. Например, портфель представляет собой совокупность финансовых инструментов с первоначальной инвестиционной стоимостью, общей текущей стоимостью, историей ценностей с течением времени и т.д., В то время как список представляет собой простой набор объектов. Портфель - это "тип списка" только в самом абстрактном смысле.
EDIT 2: подумайте об определении портфолио - он без исключения охарактеризован как совокупность вещей. Портфолио художников - это коллекция их произведений, портфель веб-дизайнеров - это коллекция их веб-сайтов, портфель инвесторов состоит из всех финансовых инструментов, которыми они владеют, и так далее. Так что нам нужен список (или какой-то вид) для представления портфеля, но это никоим образом не означает, что портфолио является типом списка!
предположим, что мы решили разрешить Portfolio наследовать из List. Это работает до тех пор, пока мы не добавим Фондовый или Бонд или Драгоценный металл в Портфолио, а затем внезапно неправильное наследование больше не работает. Или предположим, что нас попросят моделировать, скажем, портфолио Билла Гейтса, и найти, что в Листе не хватит памяти;-) Более реалистично, после будущего рефакторинга мы, вероятно, обнаружим, что мы должны наследовать от базового класса, такого как Asset, но если мы уже унаследовали от List, тогда мы не можем.
Резюме: различать структуры данных, которые мы выбираем для представления концепции, и семантику (иерархию типов) самого понятия.
Первый, потому что вы должны попытаться одобрить композицию по наследованию, когда сможете.
Это зависит от того, определяет ли бизнес Портфель как группу (и только группу) средств. Если есть даже отдаленная возможность того, что он может содержать другие объекты, скажем "свойство", затем перейдите с опцией 1. Идите с опцией 2, если есть сильная связь между группой фондов и концепцией портфолио.
В отношении расширяемости и полезности 1 есть небольшое преимущество перед 2. Я действительно не согласен с концепцией, что вы всегда должны поддерживать друг друга. Это действительно зависит от того, что представляют собой реальные концепции реальной жизни. Помните, что вы всегда можете рефакторировать.
^ Для большинства случаев всегда. Если это открыто, то, очевидно, нет.
Я бы выбрал вариант (1) - состав, так как в конечном итоге у вас могут быть атрибуты, характерные для портфеля, а не средства.
Первый, потому что он "состоит из". = > Состав
Я буду отличаться тем, что, по-видимому, является общим мнением. В этом случае я считаю, что портфель - это немного больше, чем сбор средств... Используя наследование, вы разрешаете использование нескольких конструкторов, как в
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
}
и индексаторы, как в:
public Fund this[int fundId] { get { return this.fundList[fundId]; } }
и т.д.. и др.
если вы хотите иметь возможность обрабатывать переменные типа Portfolio как совокупность фондов с соответствующим синтаксисом, тогда это лучший подход.
Portfolio BobsPortfolio = new Portfolio(Bob);
foreach (Fund fund in BobsPortfolio)
{
fund.SendStatement();
}
или что-то вроде этого
Корабль отношений IS-A представляет наследования и корабль отношения HAS-A представляет композицию. Для вышеупомянутого сценария мы предпочитаем композицию, так как PortfolioA имеет List и это не тип List. Наследование используется, когда портфолио A является типом списка, но здесь это не так. Следовательно, для этого сценария мы должны предпочесть композицию.