140 / 72 / 26
Регистрация: 29.06.2015
Сообщений: 186
|
||||||||||||||||
1 | ||||||||||||||||
Как обратится к обьекту класса, являющегося наследником абстрактного класса31.07.2015, 23:58. Показов 6943. Ответов 131
Метки нет (Все метки)
Здравствуйте!
У меня есть 4 класса: один виртуальный, следующие 2 - наследуют виртуальный класс и последний класс содержит указатель на виртуальный класс (динамический массив, который растет от методов buildCar и buildTruck). eFuel - это также класс, который содержит еще класс, но в данном вопросе они не принимают участия. Вопрос: как через указатель четвертого класса доступится к наследующим классам?
0
|
31.07.2015, 23:58 | |
Ответы с готовыми решениями:
131
как узнать,является данный объект класса А1 наследником класса А2 Как полю класса А обратится к приватной функции класса А? Как обратиться из конструктора базового абстрактного класса к свойству-массиву класса наследника Поместить в динамически расширяемый массив объекты класса, производные от базового абстрактного класса |
01.08.2015, 14:24 | 61 |
Ок, а как правильно?
friend в действительности мог бы предлагать больше, и точнее давать возможность задавать более жесткие правила доступа. Выше я приводил пример с friend, мне нужен был доступ только к закрытым конструкторам классов, вместо этого я получал доступ ко всем закрытым членам.
0
|
:)
4773 / 3267 / 497
Регистрация: 19.02.2013
Сообщений: 9,046
|
|
01.08.2015, 14:36 | 62 |
Либо всё, либо ничего. Если хочется получить доступ только к какой-то конкретной части, то нужно эту часть выделить в самостоятельную сущность. Например сделать вложенный класс. Требовать чтобы friend класса имел доступ к ограниченном набору членов этого класса, довольно странно, т.к. это уже был бы и не друг класса вовсе.
0
|
01.08.2015, 14:37 | 63 |
Ну это то как по факту есть, а не так как следовало бы.
Что это как не нарушение инкапсуляции когда предоставляется больше прав чем нужно/предполагается? Как мне "выделить" конструктор?
0
|
18840 / 9839 / 2408
Регистрация: 30.01.2014
Сообщений: 17,280
|
|
01.08.2015, 14:37 | 64 |
Об этом много где есть.
Например для начала, можно было бы не давать доступ к данным класса всему ChainOfGasStation, а только методу, занимающемуся созданием экземпляра. Т.е. этот метод заменяет собой конструктор + устанавливает отношения взаимодействия и контракт, мы подчеркиваем, что только ChainOfGasStation::addCarGasStation может создать экземпляр. В этом случае не будет нарушения. Т.к. настоящий конструктор тоже имеет доступ ко всем данным - это равноценный обмен. Уже был аналогичный вопрос, я постарался расписать все подробно (со ссылками на источники, чтобы не быть голословным): https://www.cyberforum.ru/post7804066.html
1
|
01.08.2015, 14:42 | 65 |
Ну так дела не в соответствии названиию, а в затребованой возможности, как это назвать дело второстепенное.
Добавлено через 2 минуты Вполне логично, так и стоило сделать изначально, я просто не хотел заморачиваться с предъобявления только ради примера. Но это никак не меняет сути проблемы из того метода нам по прежнему доступны все внутренности, когда нужен только конструктор.
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
01.08.2015, 14:56 | 66 |
нету никакой проблемы.
и не нужно её создавать: не нужно пытаться сделать убер-защиту класса от злобных хаккеров, которые будут искать уязвимости в его защите. это - зряшная трата времени и сил. задача - уберечься лишь от ничайных ошибок.
0
|
18840 / 9839 / 2408
Регистрация: 30.01.2014
Сообщений: 17,280
|
|
01.08.2015, 14:57 | 67 |
Тем не менее это важное различие и снижает ценность примера, как доказательства "нарушения инкапсуляции".
В этом нет нарушения инкапсуляции. Пересмотри свой взгляд на эту проблему. Метод, который мы определили как friend (addCarGasStation), логически становится частью интерфейса CarGasStation. Нет ничего плохого в том, что ему доступны данные. Он логически - часть класса. Причем декларируем мы это не откуда угодно (тогда бы это было нарушением), а из самого класса CarGasStation, т.к. класс сам себя расширяет на еще один внешний метод. Когда ты добровольно отдаешь что-то - это не воровство, так ведь? Поэтому Cтрауструп пишет о том, что человек, который пишет про однозначное нарушение инкапсуляции через friend - просто не до конца понимает терминологию С++. Но если хочется еще больше, то можно разбить наш класс на собственно создающую часть и часть с данными\логикой. Сделать другом только создающую часть, т.к. friend не распространяется на наследование. Техническая возможность ограничить еще больше, существует.
0
|
01.08.2015, 15:08 | 68 |
В данном случае friend как продавец в супермаркете вы покупаете товар, а в место сдачи продавец вам дает жвачку и еще какую фигню которая вам не нада совсем.
Дело не в защите, а логике вешей. Когда говоришь хочу именно это и получаешь что что просишь без всяких довесков. Ну так это и дает возможность к ошибится ибо не соблюдается логика. А человек который читает код должен прилогать большие усилия что бы понять для чего именно тут открыли все потроха... Если немного пофантазировать то можно было бы придумать что-то вроде: Остался бы вопрос к целесообразности этого в плане реализации.
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
01.08.2015, 15:13 | 69 |
дело в том, что проблема надуманная.
трех простых модификаторов доступа хватает за глаза. в том числе для установления более жестких контрактов в случае необходимости, или параноидальности разработчика. ну вот нужно мне запретить создавать классы кому попало. я выделил друга - функцию make. функция make не занимается ничем, кроме создания. ну и какие здесь проблемы с логикой? человек читает: "функция make создает объекты" - это все, что ему нужно знать, для того, что бы пользоваться. все остальное - инкапсуляция. хотя конечно, увидев, что конструкторы закрыты, не нужно иметь семи пядей во лбу, что бы без всякой документации понять, что делает функция с именем make, и зачем ей дружеские полномочия. такой подход провоцирует чрезмерное раздутие правил без всякой необходимости. синтаксис полюсов итак считается перегруженным. нет причин, грузить его ещё больше вещами, которые никаких реальных проблем не решают.
0
|
01.08.2015, 15:17 | 70 |
Да ну ладно... я описал проблему и ее решение.
Как по мне значительная часть новшеств С++11 ничего не решает. Добавлено через 1 минуту Откуда он это читает, он видит фреанд в классе и тут чешит репу... Потом лезит в этот класс-друг и там смотрит и чешит репу.... И так может метаться кобанчиком от одного к другому несколько раз.
0
|
18840 / 9839 / 2408
Регистрация: 30.01.2014
Сообщений: 17,280
|
|||||||||||
01.08.2015, 15:18 | 71 | ||||||||||
Именно так. Логика тут едина. Вот пример:
Теперь делаем так:
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
01.08.2015, 15:21 | 73 |
ничем не обоснованное.
вы вообще осознаете, что по сути то, что вы предлагаете, это равносильно тому, что бы отдельным частям класса ограничить доступ к другим частям этого же класса?
0
|
01.08.2015, 15:26 | 74 |
Я чет не понял что пример демонстрирует то?
Добавлено через 47 секунд О_о вы наконец то поняли... Да именно к этому я виду:
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||||
01.08.2015, 15:27 | 75 | |||||
нафига? Добавлено через 1 минуту теперь осталось и вам понять: потому что именно на этот нюанс пытается обратить ваше внимание господин DrOffset
0
|
18840 / 9839 / 2408
Регистрация: 30.01.2014
Сообщений: 17,280
|
|
01.08.2015, 15:33 | 76 |
Там все написано.
Демонстрирует то, зачем вообще нужен friend. Это альтернативный способ организации интерфейса. Когда мы пишем метод в классе, то почему у нас не возникает желания оставить ему в пользование только часть данных? Сказать: метод x класса А имеет право доступа только к данным а и b класса А, но к данным c и d - не имеет. Пример демонстрирует, что для friend правила такие же как для членов класса. Точно так же как не существует подобного ограничения для членов класса, не существует его и для friend.
0
|
01.08.2015, 15:33 | 77 | |||||
Я не узнаю пока не полезу в hardcore() где увижу что в hardcore() где возможно вызываются закрытые методы и мне опять нужно будет вернуться к классу sample
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
||||||
01.08.2015, 15:35 | 78 | |||||
а если так?
0
|
01.08.2015, 15:44 | 79 |
А при чем тут маразм? Дело то не ограничиватеся только созданием(make) могу выполнятся и другие действия.
hardcore() вполне может быть вменяемым названием, но ее имя не скажет точно с чем из защиенных внутренностей данного класса она работает, для этого мне придется листать код к её определению. Т.е менее информативно.
0
|
8739 / 4317 / 960
Регистрация: 15.11.2014
Сообщений: 9,760
|
|
01.08.2015, 15:56 | 80 |
1.
пользователя не касается, что там под капотом чужого класса. 2. разработчик знает, что под капотом его собственного класса. 3. если функция называется "создавалка", но на деле - "прибивалка", то у такого кода проблемы посерьезнее, нежели "отсутствие инкапсуляции от себя самого". Добавлено через 3 минуты имя функции-члена должно отражать умение механизма. hardcore в сферическом ваккуме мне ни о чем не говорит, например. имя не должно никак светить подробности реализации.
0
|
01.08.2015, 15:56 | |
01.08.2015, 15:56 | |
Помогаю со студенческими работами здесь
80
Метод абстрактного класса не видит переменные дочернего класса Вызов функции класса, который наследуется от абстрактного класса Как инициализировать члены класса, являющегося параметром шаблона Как обратится к объекту класса Как обратиться к конструктору абстрактного класса Как вызвать функцию из абстрактного класса? Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |