ООП - страница 9
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Очень здравые мысли озвучиваете господа, но как бы найти эту свою желанную архитектуру?!) Вечно что то приходится менять и переделывать и кажется этому нет предела)).
Сам ООП использую относительно недавно и классы больше как отдельные части без наследования. Вот и назрели несколько вопросов по наследованию, буду благодарен за подсказку.
1. Класс потомок может пользоваться членами и методами родителя, а родитель может так же пользоваться методами своих наследников? Или нужно только явно создавать экземпляр класса наследника, чтобы получить доступ к его методам? Тогда следующий вопрос как это делать если эти классы в разных файлах, получается они должны ссылаться друг на друга.
2. Или это в принципе не правильных подход в ООП когда родителю нужно использовать методы наследников? Сейчас у меня классы не зависимы, и методы вызываются явно через экземпляры, но все равно выстраивается иерархия, опять же вопрос в эффективности такого подхода.
Родитель ничего не знает о наследниках. И знать не должен. Смысл наследования в том, что требуется тот же класс, что и родительский, но с расширенным функционалом.
Спасибо, значит все таки не до конца представлял взаимодействие, всегда казалось что родитель главнее и должен все знать о своих наследниках, и получается если выстроить такую иерархию то самый последний потомок будет самым общим. И также получается что можно выстроить только одну такую ветку так как у наследника может быть только один родитель.
А как быть с таким важным решением - "должен ли класс являться потомком другого класса или он должен содержать объект другого класса", что и когда оптимальнее использовать? Получается у меня все построено на втором принципе.
Очень здравые мысли озвучиваете господа, но как бы найти эту свою желанную архитектуру?!) Вечно что то приходится менять и переделывать и кажется этому нет предела)).
Сам ООП использую относительно недавно и классы больше как отдельные части без наследования. Вот и назрели несколько вопросов по наследованию, буду благодарен за подсказку.
1. Класс потомок может пользоваться членами и методами родителя, а родитель может так же пользоваться методами своих наследников? Или нужно только явно создавать экземпляр класса наследника, чтобы получить доступ к его методам? Тогда следующий вопрос как это делать если эти классы в разных файлах, получается они должны ссылаться друг на друга.
2. Или это в принципе не правильных подход в ООП когда родителю нужно использовать методы наследников? Сейчас у меня классы не зависимы, и методы вызываются явно через экземпляры, но все равно выстраивается иерархия, опять же вопрос в эффективности такого подхода.
Не будет предела, как минимум до тех пор, пока не осознаете способы и область применения каждой синтаксической возможности ООП.
Поверьте, лишнего/дополнительного там ничего нет :)
P.S. Сам так начинал. И в процессе работы каждое новое освоенное ключевое слово приводило к этому.Не будет предела, как минимум до тех пор, пока не осознаете способы и область применения каждой синтаксической возможности ООП.
Поверьте, лишнего/дополнительного там ничего нет :)
P.S. Сам так начинал. И в процессе работы каждое новое освоенное ключевое слово приводило к этому.Спасибо, надеюсь когда то до этого дойдет)
А как быть с таким важным решением - "должен ли класс являться потомком другого класса или он должен содержать объект другого класса", что и когда оптимальнее использовать? Получается у меня все построено на втором принципе.
Это решение должно приниматься на уровне проектирования структуры классов - тут верно отметили.
Общий принцип тут предполагает, что потомки выполняют те же действия, что и предок, но в своём контексте. Тут иногда даже удобно описать все функции класса в виде интерфейса (то есть в виде специального "пустого" класса, в котором есть только эти виртуальные функции), далее создаём несколько потомков, в каждом этот интерфейс реализуется по-своему. И дальше, когда надо пользоваться классом, пользователь должен работать именно с интерфейсом.
Таким образом получается чёткое разделение функций и полномочий. Твои классы, потомки интерфейса, делают свои действия так, как считают нужным, однако, подчиняясь заданному интерфейсу. Класс-пользователь также обращается к созданным классам через интерфейс, то есть, получается, что ему не требуется знать о всех тонкостях реализации классов, не надо знать о контексте выполняемых задач.
Наследование удобно при повторном использовании кода.
Скажем, вот в этом сообщении у меня код метода МНК от нулевой до третьей степени. Предназначен для аппроксимации точек графика плавной прямой, параболой или кубикой. При необходимости берём класс ядра МНК, наследуемся от него, и перегружаем функции, которые должны возвращать число точек и их координаты. Когда нужна аппроксимация - вызываем аппроксимирующую функцию, которая расчитывает коэффициенты аппроксимирующего полинома (пользуясь перегруженными функциями), и выдаёт эти коффициенты при возврате. Тебе не требуется ничего знать о реализации метода МНК. Весьма удобно.Это решение должно приниматься на уровне проектирования структуры классов - тут верно отметили.
Общий принцип тут предполагает, что потомки выполняют те же действия, что и предок, но в своём контексте. Тут иногда даже удобно описать все функции класса в виде интерфейса (то есть в виде специального "пустого" класса, в котором есть только эти виртуальные функции), далее создаём несколько потомков, в каждом этот интерфейс реализуется по-своему. И дальше, когда надо пользоваться классом, пользователь должен работать именно с интерфейсом.
Таким образом получается чёткое разделение функций и полномочий. Твои классы, потомки интерфейса, делают свои действия так, как считают нужным, однако, подчиняясь заданному интерфейсу. Класс-пользователь также обращается к созданным классам через интерфейс, то есть, получается, что ему не требуется знать о всех тонкостях реализации классов, не надо знать о контексте выполняемых задач.
Наследование удобно при повторном использовании кода.
Скажем, вот в этом сообщении у меня код метода МНК от нулевой до третьей степени. Предназначен для аппроксимации точек графика плавной прямой, параболой или кубикой. При необходимости берём класс ядра МНК, наследуемся от него, и перегружаем функции, которые должны возвращать число точек и их координаты. Когда нужна аппроксимация - вызываем аппроксимирующую функцию, которая расчитывает коэффициенты аппроксимирующего полинома (пользуясь перегруженными функциями), и выдаёт эти коффициенты при возврате. Тебе не требуется ничего знать о реализации метода МНК. Весьма удобно.Благодарю за наводку на интерфейсы, с этим еще не работал. Хотя по сути сейчас что то подобное выстраиваю на классах. В целом структура представляет основной класс в который стекаются другие классы через объекты, как бы наследование наоборот.