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