Должен ли я создавать экземпляр коллекции или наследовать от коллекции?

Question

Я задавал себе этот вопрос несколько раз, когда создавал классы, особенно те, которые связаны с коллекциями, но я никогда не придумал удовлетворительного ответа. Это вопрос проектирования ООП.

Например, в программе регистрации чековой книжки говорят, что у меня есть класс BankAccount. BankAccounts содержат данные, включающие имя учетной записи, тип учетной записи (перечисление чеков, сохранение, ...) и другие данные, но наиболее важным является набор Adjustment s (пополнение или снятие) в учетной записи .

Здесь у меня есть два варианта для хранения коллекции корректировок:

1. Создайте коллекцию и сохраните ее в качестве члена в классе BankAccount. Это все равно что сказать: «BankAccount имеет набор корректировок».
2. Наследовать от коллекции. Это все равно, что сказать: «BankAccount - это коллекция корректировок».

Я думаю, что оба решения интуитивно понятны, и, конечно, оба имеют свои преимущества и недостатки. Например, создание экземпляров позволяет классу (в языках, которые допускают только один базовый класс) наследовать от другого класса, в то время как наследование от коллекции позволяет легко управлять методами Add, Remove и другими без необходимости писать суррогатные методы для переноса 'те.

Итак, в таких ситуациях какой подход лучше?

Answer 1

Для меня банковский счет имеет набор корректировок. Банковский счет не является набором корректировок, потому что он «является» гораздо большим: он также «является» именем и типом и т. Д.

Итак, в вашем случае (и аналогичных случаях) я предлагаю вам собрать коллекцию внутри вашего класса.

В случае сомнений избегайте наследования. : -)

Я могу аргументировать это дальше. Чтобы правильно использовать наследование, подкласс должен удовлетворять принципу подстановки Лискова ; это означает, что в вашем случае BankAccount должен быть допустимым типом везде, где ожидается Collection. Я не думаю, что это так, потому что Collection, вероятно, предоставляет такие методы, как Add() и Remove(), тогда как вы захотите установить некоторый контроль над добавлением и удалением корректировок с вашего банковского счета, а не позволять людям добавлять и удалите их свободно.

Answer 2

Определить, определенно.

Я согласен с другими постерами о том, что банковский счет "больше", чем просто набор других предметов. Или, может быть, вы выбрали пример, который действительно кричит «создать экземпляр».

Примеры:

• Что произойдет, если вашему банковскому счету понадобится вторая коллекция совершенно разных предметов? (Пример: собрание людей, которые могут работать с ним, например, муж и жена, например, сбор кредитных карт, учетных записей PayPal или чего-либо еще, что может «работать» на вашем банковском счете).
• В зависимости от языка коллекция предоставляет слишком много информации: если другому объекту требуется доступ к настройкам ... скажем, для отображения истории ваших движений на веб-странице, вы автоматически выставляете свою «коллекцию» для инъекции, удаления и т. .

Answer 3

Лично я бы сказал, BankAccount имеет коллекцию Adjustment. Вероятно, у него будут другие свойства, которые не относятся исключительно к тому, что было депонировано или снято (клиент, тип банковского счета и т. Д.).

С точки зрения дизайна, мой BankAccount объект будет предоставлять свойство поздней загрузки типа Adjustments.

С точки зрения использования в коде, я бы создал экземпляр банковского счета, и если бы мне нужно было узнать, что входило и выходило из счета, я использовал бы выставленное свойство. BankAccount будет основным объектом, отвечающим за предоставление корректировок, связанных только с созданным экземпляром счета.

Answer 4

Я думаю, что чрезмерно увлекаться семантикой, такой как «это больше, есть или имеет», немного опасно - в конце концов, важно то, насколько хорошо ваш дизайн решил проблему, насколько легко обслуживаемо и т. д. На самом деле, лично, поворотным моментом в моем понимании объектно-ориентированного программирования стало избавление от «объектов как существительных». Когда вы переходите к нему, объекты - это абстракция на один уровень выше функции, ничего более или менее.

Это был долгий путь, чтобы сказать "имеет". :-) Подклассы сложны, использовать легко.