Вопрос знатокам ООП. - страница 43
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Петр, Вам очень рекомендую
https://en.wikipedia.org/wiki/Code_Complete
Пётр. Потому и говорю - не нужно бездумное наследование. Чётко разделение и классификация.
Приведу пример:
Категория "Плод" - базовый объект.
Классы - "Фрукты", "Овощи" - наследники класса "Плод".
Класс "Фрукты" - родитель классам - Киви, Манго, Лимон, Апельсин.
Появляется новая категория: "Цитрусовые".
Ставим ее между классом "Фрукты" и его наследниками - Киви, Манго, Лимоном и Апельсином.
"Цитрусовые" - родитель для Лимона и Апельсина.
Далее, - скрещиваем Манго и Лимон и получаем - объект Ли-Манго.
Объект частично содержит свойства цитрусовых и частично - не цитрусовых. У него ДВА родителя и оптимизировать эту Иерархию нельзя.
Так получаем множественное наследование объекта "Ли-Манго" и двойной путь к базовому объекту "Плод": через цепочку цитрусовые и через цепочку "Манго".
В этих цепочках мы должны обойти лишние свойства Родителей, чтобы сохранить индивидуальность "Ли-Манго".
Петр, это называется: самому себе мозг трахать - придумывать непреодолимые сложности. Нужно конкретизировать задачу и под нее делать классы.
Зачем вводить промежуточный класс "цитрусовые"? Может быть задача решается просто добавлением свойства "цитрусовые" в динамический список.
Петр, это называется: самому себе мозг трахать - придумывать непреодолимые сложности. Нужно конкретизировать задачу и под нее делать классы.
Зачем вводить промежуточный класс "цитрусовые"? Может быть задача решается просто добавлением свойства "цитрусовые" в динамический список.
И это. ООП это все таки средство программирования, а не средство работы с данными (как бы это правильно разделить). Средство работы с данными - это база данных.
Три таблицы. В одной таблице две колонки: id фрукта и его название. В другой две колонки: id свойства и его название. В третье две колонки: id фрукта, id свойства.
В результате имеется возможность безграничного добавления новых свойств, присваивания их фруктам и, таким образом, получения любого нового фрукта.
Средства решения задачи должны соответствовать задаче.
Петр, это называется: самому себе мозг трахать - придумывать непреодолимые сложности. Нужно конкретизировать задачу и под нее делать классы.
Зачем вводить промежуточный класс "цитрусовые"? Может быть задача решается просто добавлением свойства "цитрусовые" в динамический список.
Пусть так.
Но как быть со скрещиванием свойств двух объектов, порождающих новый объект? Новый объект будет частично наследовать свойства двух других.
Как реализовать его "частичное" наследование между несколькими объектами(его родителями) и базовым объектом?
Пусть так.
Но как быть со скрещиванием свойств двух объектов, порождающих новый объект? Новый объект будет частично наследовать свойства двух других.
Как реализовать его "частичное" наследование от нескольких других объектов?
Применением соответствующего алгоритма для решение данной конкретной задачи.
ООП - это средства программирования, а не средство описания окружающего мира, как бы там оно не соответствовало друг другу с некотороый точки зрения.
И это. ООП это все таки средство программирования, а не средство работы с данными (как бы это правильно разделить). Средство работы с данными - это база данных.
Три таблицы. В одной таблице две колонки: id фрукта и его название. В другой две колонки: id свойства и его название. В третье две колонки: id фрукта, id свойства.
В результате имеется возможность безграничного добавления новых свойств, присваивания их фруктам и, таким образом, получения любого нового фрукта.
Средства решения задачи должны соответствовать задаче.
Дело не в свойствах, а в наследовании. То есть - в распределении свойств и методов между объектами.
Новые объекты будут связывать свойства прежних объектов в разных комбинациях, что увеличит сложность их цепочек к базовому объекту.
Дело не в свойствах, а в наследовании. То есть - в распределении свойств и методов между объектами.
Новые объекты будут связывать свойства прежних объектов в разных комбинациях, что увеличит сложность их цепочек к базовому объекту.
Сами объекты не будут этого делать. Выбираешь из базы свойства оного фрукта, свойства другого фрукта, комбинируешь (что-то оставляешь, что-то выбрасываешь) - получаешь новый фрукт - добавляешь его в базу.