|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
|||||||||||
Можно ли не передавать значения из конструктора дочернего класса в базовый19.04.2014, 11:14. Показов 8069. Ответов 35
Метки нет (Все метки)
У меня есть абстрактный класс (пусть будет A), от которого наследуются 4 класса (соответственно, B,C,D,E).
В конструкторах дочерних классов не требуется указания никаких других переменных кроме тех, что есть в конструкторе базового класса (пусть это будут int x и int y). Во время создания объекта класса и далее, во время присваивания и изменения значений переменных, необходимо проверять допустимость значений. Для каждого из дочерних классов параметры свои. Таким образом, если описать кратко, выходит что-то наподобие такого (проверки значений упрощу до минимума ибо суть вопроса не в них): Базовый класс A: Кликните здесь для просмотра всего текста
Класс, к примеру, B (одного класса хватит для описания вопроса, остальные классы работают по аналогии с этим) Кликните здесь для просмотра всего текста
Теперь к сути вопроса. В вышеописанном коде, по идее, при инициализации элемента через конструктор происходит следующее: Кликните здесь для просмотра всего текста
1. Переменные из конструктора дочернего класса передаются в конструктор базового класса. 2. В конструкторе переменные передаются в свойства. 3. В свойствах значение переменной передается в абстрактный метод проверки. 4. Абстрактный метод означает, что, по сути, выполнится соответствующий метод дочернего класса, в него значения и передаются. 5. Метод дочернего класса возвращает результат в свойства базового класса. 6. В зависимости от результата происходит присваивание или генерация исключения. Но можно описать код по другому: 1. Не передавать значения из конструктора дочернего класса в базовый. 2. Выполнять проверку значений вызовом метода (из дочернего конструктора вызов метода этого же класса). 3. Сделать переменные базового класса не private, а protected; и присваивать им значения после проверки. Вопрос: Какое написание кода будет более правильным? З.Ы. Может, есть еще варианты, не рассмотренные мной, если предложите что-то другое - милости просим =)
0
|
|||||||||||
| 19.04.2014, 11:14 | |
|
Ответы с готовыми решениями:
35
Копирование дочернего класса в базовый
|
|
|
||
| 19.04.2014, 17:14 | ||
|
fadeinmad, Microsoft'овская реализация обработчиков событий Вас тогда должна просто в кому ввести, если Вы так относитесь к примеру с private методом, который кроме самого разработчика не вызовет никто.
С точки зрения грамотного публичного метода там будет проверка на правильное значение и ArgumentException в случае чего. Специально же для себя создавать Enum с возможными значениями мало кто будет, по крайней мере не сразу. Сам Гради утверждает замечательную вещь - ни одна сложная система сразу не заработает, любая сложная система эволюционирует из простой и работающей.
0
|
||
|
713 / 680 / 126
Регистрация: 30.03.2012
Сообщений: 1,124
|
||
| 19.04.2014, 17:23 | ||
или просто коряво выразили мысль?)
0
|
||
|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
|||||
| 19.04.2014, 17:29 [ТС] | |||||
|
К тому же, мы все-таки слишком далеко ушли от темы. Добавлено через 5 минут
0
|
|||||
|
|
||
| 19.04.2014, 17:32 | ||
|
0
|
||
|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
|
| 19.04.2014, 17:32 [ТС] | |
|
К тому же, свойства - прямое следствие применения инкапсуляции как одного из принципов ООП. А вот пренебрежение принципа наследования и использование вместо него switch уже нарушение ООП. Я же не говорю, что свитч не надо использовать, я говорю, что его не стоит использовать там, где более уместно наследование.
0
|
|
|
|
||
| 19.04.2014, 17:34 | ||
0
|
||
|
713 / 680 / 126
Регистрация: 30.03.2012
Сообщений: 1,124
|
|||
| 19.04.2014, 17:39 | |||
собственно из того что это вызов метода, следует что он несколько менее шустр, чем прямое чтение поля Добавлено через 3 минуты
то, что кто то реализовал в .net класс еще не значит что эта реализация является самой лучшей и подходящей к каждому конкретному случаю к примеру посмотрите на реализацию классов кодировки в .net, мешанина unsafe-кода, вероятно потому, что .net используется в самых разных по нагрузке проектах и просадка производительности в нем неприемлима однако, если вам понадобится дописать свою кодировку (например, потому что майкрософт решили, что в сильверлайте некоторые кодировки не нужны), вряд ли вы будете писать тонны unsafe-кода, особенно если пара милисекунд производительности вам не критична
0
|
|||
|
|
||
| 19.04.2014, 17:40 | ||
|
0
|
||
|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
|
| 19.04.2014, 17:43 [ТС] | |
|
0
|
|
|
|
||
| 19.04.2014, 17:46 | ||
|
В этом как раз и прелесть наследования: в зависимости от условия (к примеру, прописанного в файле конфигурации) приложение решает, что ему выбрать. И самое хорошее-при смене возвращаемого значения не надо менять код, а только изменить строку в файле конфигурации.
0
|
||
|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
|||||||
| 19.04.2014, 22:51 [ТС] | |||||||
|
Я бы сделал в базовом классе абстрактный метод "Вернуть тип". Потом, при создании наследников описывал бы метод, как возврат их типа с помощью базовой переменной.
Таким образом, при вызове метода GetChildElement() мы автоматически получаем элемент дочернего класса в родительской переменной. Взятие текущего элемента через this.MyChildValue или создание нового через new MyChild(/*параметры*/) - на выше усмотрение в зависимости от поставленной задачи.
0
|
|||||||
|
|
||
| 19.04.2014, 23:03 | ||
![]() Ну а по операторам - так можно и половину языка выкинуть (хотя мне, честно, не понятно, чем и что тот же switch нарушает). Нормальный оператор, как и все.
0
|
||
|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
||
| 19.04.2014, 23:08 [ТС] | ||
|
В принципе, тут получаются примерно те же 3-4 строки на каждый класс. Но теперь, при создании наследника, вам достаточно переопределить в нем этот метод, а не лезть в базовый класс и менять в нем методы. Базовый класс после его создания мы даже не трогаем. Нет никаких числовых параметров, которые надо запоминать и куда-то передавать. Не надо ничего такого. Код становится понятнее, надежнее и проще, как бы там ни казалось.
0
|
||
|
52 / 45 / 4
Регистрация: 07.10.2010
Сообщений: 95
|
|
| 19.04.2014, 23:35 | |
|
Почему то все, начиная изучать ООП особо любят наследование. И считают что оно помогает от дублирования кода.
Нет. Оно делает зачастую сложно переносимый и сложно расширяемый код. Ну к примеру - Нам нужна та же проверка, но уже другого класса. Как ее выдрать со старой реализации и прикрутить к новой. Или например - при этих условиях проверяем та, при других так. Городить два класса? Вводить всякие свичи в проверку? Я б наверное всю валидатционную логику исключил из сущности. Создал бы класс Validator, который реализует какой то интерфейс IValidator и принимает в конструкторе валидируюмую сущность. И еще один класс - MultyTargetValidation - а он уже содержал бы в себе коллекцию IValidator, и просто проходился по коллекции и запeскал какой нибудь Validate()
0
|
|
|
|
|||||||||||
| 19.04.2014, 23:40 | |||||||||||
|
Нет, я так и не понял, к чему все это: один метод, второй... Наследник автоматически является и базовым , и к чему все эти методы??? Вот Вам, классическое наследование. Нигде ничего не переопределяется. Но при изменении достаточно заменить одну строчку, и тип соединения сразу меняется. Безо всяких переписываний методов. Разве это не удобно? Именно это и есть наследование (и его применение).
0
|
|||||||||||
|
9 / 9 / 2
Регистрация: 25.11.2012
Сообщений: 115
|
|||
| 20.04.2014, 00:08 [ТС] | |||
|
В случае, когда эта функция присуща нескольким различным классам, не связанным "родственными" связями, действительно удобнее использовать интерфейсы. По сути, они для этого и созданы. И, если несколько абстрагироваться, просто предоставляют возможность множественного наследования для обобщения методов работы со схожими, но разнородными данными. Так что это не нарушает, а просто расширяет возможности ООП. Но, возвращаясь к нашей ситуации, целесообразнее использовать наследование, потому что данные методы стопроцентно не будут востребованы в других классах. А если продолжать вашу идею, то можно тогда сразу для написания небольшой программы сразу создавать множество интерфейсов в стиле "а вдруг они понадобятся еще"... А потом и каждый класс компилировать в отдельной библиотеке, потому что "а вдруг он понадобится мне в другом проекте..."
0
|
|||
| 20.04.2014, 00:08 | |
|
ООП в C++: Вызов родительского конструктора с параметром при создании объекта дочернего класса
Почему при вызове конструктора из конструктора нельзя передавать this как аргумент? Как передавать значения строкового типа в конструктор через объект класса?
Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Про "Windows must die!"
kumehtar 04.11.2026
Знаете, чет накатило. . . .
Когда-то это было почти боевым кличем: мол, нормальный человек сидит на DOS, OS/ 2 или Linux, а вот это вот - Must Die. А теперь человек произносит «мастдай» с усмешкой - и. . .
|
Красочные поля с номером страницы svg+background-image
russiannick 04.11.2026
Красочные поля с номером страницы не менее важны чем в эпоху бумажных книг.
Посему спешу представить почтеннейшей публике этот важный инструмент который эти поля и формирует.
В процессе разработки. . .
|
Вступаем в новую фазу генерации favicons, векторную.
russiannick 02.11.2026
Теперь нет нужды скрывать что используется простой svg. Исходный код изображения помещаем в поле и жмем кнопку. Исходник преобразуется в вид корректный для помещения в favicon или в url(). Нажатие. . .
|
Генератор паролей (вариант №4)
Maks 01.11.2026
После публикации 3-го варианта генератора паролей, разослал его своим коллегам (с целью оценки), в итоге были получены следующие рекомендации:
1. Вернуть возможность использования знаков | 1 l I;. . .
|
|
Генератор паролей (вариант №3)
Maks 30.10.2026
Финальная версия генератора паролей 1С.
Доработка решения в этот раз коснулась только визуальной части, а именно, добавлен реквизит ДопПараметры (тип Булево), который скрывает/ отображает реквизиты:. . .
|
Магическое мышление и магия, современная наука не отличима от магии (говорит ИИ Джемени)
zorxor 30.10.2026
Джемени, расскажи, пожалуйста, что такое магическое мышление, что такое магия, почему современная наука чем-то напоминает магию?
Фраза «Любая достаточно развитая технология неотличима от магии». . .
|
За какое время ИИ может подобрать пароль по хешу (рассказывает Джемени ИИ)
zorxor 30.10.2026
Расскажи, Джемени, если известен хэш МД5, например, за сколько ИИ сможет подобрать соответствующий пароль?
Искусственный интеллект (ИИ) может подобрать простой или средний по сложности пароль по. . .
|
Кто убил Suno? Почему наше солнышко погасло? (диалог с ИИ Джемени)
zorxor 30.10.2026
Как убивали Suno. Хронология.
«Убийство» музыкальной нейросети Suno — это затяжной процесс, в котором технологический хайп стартапа разбился о жесткую реальность судебных исков от гигантов. . .
|