При проектировании классов какие должны быть предпосылки
к объявлению метода protected или private
Мне кажется, что методы которые специфичны для конкретно
этого класса должны объявляться private, а остальные, но
которые не должны быть public должны объявляться protected.
Корректно сформулировать вопрос не удалось, но надеюсь
вы меня поняли.
pivoo -> "Применение protected-методов" :
p> При проектировании классов какие должны быть предпосылки к объявлению p> метода protected или private
p> Мне кажется, что методы которые специфичны для конкретно этого класса p> должны объявляться private, а остальные, но которые не должны быть p> public должны объявляться protected.
p> Корректно сформулировать вопрос не удалось, но надеюсь вы меня p> поняли.
p> Правильно ли я думаю?
Тут все просто.
Сделай все методы private изменяй из на protected/public при необходимости,
т.е. когда другой класс захочет их заюзать.
Здравствуйте, hrg, Вы писали:
hrg>pivoo -> "Применение protected-методов" :
p>> При проектировании классов какие должны быть предпосылки к объявлению p>> метода protected или private
p>> Мне кажется, что методы которые специфичны для конкретно этого класса p>> должны объявляться private, а остальные, но которые не должны быть p>> public должны объявляться protected.
p>> Корректно сформулировать вопрос не удалось, но надеюсь вы меня p>> поняли.
p>> Правильно ли я думаю?
hrg>Тут все просто. hrg>Сделай все методы private изменяй из на protected/public при необходимости, hrg>т.е. когда другой класс захочет их заюзать.
Это не правильный подход к проектированию классов (исходя из правила 32 в
книге Скотта Майерса "Наиболее эффективное использование С++", почему-то
я ему доверяю...). Нужно делать так, что бы переделывать, даже по мелочи не
приходилось.
Здравствуйте, pivoo, Вы писали:
P>Правильно ли я думаю?
Методы, являющиеся интерфесом класса, т.е. которые будут дергаться
другими классами — public
Методы, используемые иерархией классов с твоим проектируемым
классом в корне — protected.
Все методы, специфичные только для данного класса — private.
Здравствуйте, pivoo, Вы писали:
P>При проектировании классов какие должны быть предпосылки P>к объявлению метода protected или private...
Рискуя получить по шее от адептов создания иерархий классов... позволю себе посоветовать такую штуковину:
1) Объявляй интерфейс класса как абстрактный класс — у интерфейса, очевидно, все public.
2) В классе реализующем этот интерфейс все делай private кроме, разумеется, уже описанного интерфейса.
3) Этот класс никому внешнему не показывай, а показывай только интерфейс и фабрику по производству объектов реализующих этот интерфейс.
4) Забудь про все остальное наследование, пользуйся только двух уровневым ИНТЕРФЕЙС -> РЕАЛИЗАЦИЯ.
5) Вместо иерархий наследования используй композицию полиморфных объектов и абстрактные фабрики.
В некоторых случаях это будет приводить к большему количеству кода, но оно того стоит. Сопровождать такую систему гораздо проще.
pivoo -> "Re[2]: Применение protected-методов" :
hrg>> Тут все просто. hrg>> Сделай все методы private изменяй из на protected/public при hrg>> необходимости, hrg>> т.е. когда другой класс захочет их заюзать.
p> Это не правильный подход к проектированию классов (исходя из правила p> 32 в книге Скотта Майерса "Наиболее эффективное использование С++", p> почему-то я ему доверяю...). Нужно делать так, что бы переделывать, p> даже по мелочи не приходилось.
(задумчиво) вообще то во всех современых походах, которые я видел
предлагаются итеративные методы. Хотя классический "водопад" — это конечно
соблазнительно.
korzhik -> "Re: Применение protected-методов" :
P>> При проектировании классов какие должны быть предпосылки к P>> объявлению метода protected или private
k> 1. Методы которые являются деталью реализации не должны k> вызываться напрямую клиентами класса поэтому должны быть private.
(догадливо) осталось только выяснить, каких из них являются деталью
реализации.
k> 2. Методы которые должны использоваться производными классами, но не k> клиентами на прямую, делай protected
А если они не будут ими использоваться?
k> ну это конечно всё поверхностно
ЗЫ Ты бы минусами без объяснений не разбрасывался?
Yury Kopyl aka hrg | http://id.totem.ru | "бысто сп..ил и ушел — называется
нашел..."
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Рискуя получить по шее от адептов создания иерархий классов... позволю себе посоветовать такую штуковину:
SYG>1) Объявляй интерфейс класса как абстрактный класс — у интерфейса, очевидно, все public. SYG>2) В классе реализующем этот интерфейс все делай private кроме, разумеется, уже описанного интерфейса. SYG>3) Этот класс никому внешнему не показывай, а показывай только интерфейс и фабрику по производству объектов реализующих этот интерфейс. SYG>4) Забудь про все остальное наследование, пользуйся только двух уровневым ИНТЕРФЕЙС -> РЕАЛИЗАЦИЯ. SYG>5) Вместо иерархий наследования используй композицию полиморфных объектов и абстрактные фабрики.
SYG>В некоторых случаях это будет приводить к большему количеству кода, но оно того стоит. Сопровождать такую систему гораздо проще.
Так а protected для кого придумали тогда.
И вобще, вопрос связан с тем, что хочется писать грамотные классы,
а никто не знает, будет ли конкретно этот класс использоваться
в иерархии наследования в дальнейшем(может даже и отдаленном)
будующем и не факт что мной. Поэтому хочется получить достаточно
четкие (если это вобще возможно) правила по выбору private или protected.
Здравствуйте, hrg, Вы писали:
hrg>pivoo -> "Re[2]: Применение protected-методов" :
hrg>>> Тут все просто. hrg>>> Сделай все методы private изменяй из на protected/public при hrg>>> необходимости, hrg>>> т.е. когда другой класс захочет их заюзать.
p>> Это не правильный подход к проектированию классов (исходя из правила p>> 32 в книге Скотта Майерса "Наиболее эффективное использование С++", p>> почему-то я ему доверяю...). Нужно делать так, что бы переделывать, p>> даже по мелочи не приходилось.
hrg>(задумчиво) вообще то во всех современых походах, которые я видел hrg>предлагаются итеративные методы. Хотя классический "водопад" — это конечно hrg>соблазнительно.
Итеративный-то он итеративный, но при проектировании необходимо все учитывать.
А реализация класса не должна зависеть от области его применения,
т.е. если область изменяется, хорошо спроектированный класс меняться
не должен. И итеративность тут вовсе не при чем.
hrg> Yury Kopyl aka hrg | http://id.totem.ru | Гордость мешает доходам!
Здравствуйте, Сантехник, Вы писали:
С>Методы, используемые иерархией классов с твоим проектируемым С>классом в корне — protected.
Небольшое добавление. protected — это интерфейс для наследников, причем интерфейс может быть использован в обе стороны. Либо потомком для доступа к некоторой информации базового класса, которая должная остаться недоступной окружающему миру, либо базовым классом для делегирования деталей реализации некоторого алгоритма потомку (например, паттерн "Шаблонный метод").
Второй вариант представлен во всей красе в std::basic_streambuf (C++ STL).
Здравствуйте, hrg, Вы писали:
hrg>Тут все просто. hrg>Сделай все методы private изменяй из на protected/public при необходимости, hrg>т.е. когда другой класс захочет их заюзать.
Совершенно согласен. Это так называемый минималисткий подход. Делаешь сначала все методы private, а потом по необходимости их открываешь. А вы что думали, что можно всё спроектировать изначально, как об этом говорят "гуру" типа Буча?
Hello, pivoo!
You wrote on Fri, 30 Jul 2004 10:40:55 GMT:
p> Это не правильный подход к проектированию классов (исходя из правила 32 p> в книге Скотта Майерса "Наиболее эффективное использование С++", p> почему-то я ему доверяю...). Нужно делать так, что бы переделывать, даже p> по мелочи не приходилось.
Здравствуйте, hrg, Вы писали:
k>> 1. Методы которые являются деталью реализации не должны k>> вызываться напрямую клиентами класса поэтому должны быть private.
hrg>(догадливо) осталось только выяснить, каких из них являются деталью hrg>реализации.
а чего догадываться то?
ты же сам разрабатываешь класс и знаешь для чего нужен тот или иной метод.
hrg>ЗЫ Ты бы минусами без объяснений не разбрасывался?
Время нет объяснять
я просто не согласен с таким минималистическим подходом к проектированию классов
вот и выразил своё не согласие поставив -1. На рейтинг он всё равно не скажется.
pivoo -> "Re[4]: Применение protected-методов" :
hrg>> (задумчиво) вообще то во всех современых походах, которые я видел hrg>> предлагаются итеративные методы. Хотя классический "водопад" — это hrg>> конечно соблазнительно.
p> Итеративный-то он итеративный, но при проектировании необходимо все p> учитывать. p> А реализация класса не должна зависеть от области его применения, p> т.е. если область изменяется, хорошо спроектированный класс меняться p> не должен. И итеративность тут вовсе не при чем.
Ты библиотеку,которую будеь выкладывать/продавать/разное на сторону
проектируешь или приложение, где видимость всех классов ясна?
korzhik -> "Re[3]: Применение protected-методов" :
k>>> 1. Методы которые являются деталью реализации не должны k>>> вызываться напрямую клиентами класса поэтому должны быть k>>> private.
hrg>> (догадливо) осталось только выяснить, каких из них являются hrg>> деталью реализации. k> а чего догадываться то? k> ты же сам разрабатываешь класс и знаешь для чего нужен тот или иной k> метод.
Т.к. я в основом сейчас разрабатываю архитектуру через TDD, то не совсем не
хочется тратить своем время на прогнозирование как оно возможно будет
работать. Опыт показал, что как бы ни хорошо был написал класс, все равно 2
раза переделывать
Yury Kopyl aka hrg | http://id.totem.ru | "Сегодня с нами ты не пьешь, а
завтра Родине изменишь!"
Здравствуйте, hrg, Вы писали:
k>> а чего догадываться то? k>> ты же сам разрабатываешь класс и знаешь для чего нужен тот или иной k>> метод.
hrg>Т.к. я в основом сейчас разрабатываю архитектуру через TDD,
А, ну тогда понятно.
В общем разные подходы имеют право на жизнь.
hrg> Ты библиотеку,которую будеь выкладывать/продавать/разное на сторону hrg>проектируешь или приложение, где видимость всех классов ясна?
А фиг его знает, по разному повернуться может.
Видимо все-таки вопрос не корректно задал,
мне интересно было как правильно делать,
а не как сделать что бы всего лишь компилировалось
и работало в данный момент.
Здравствуйте, pivoo, Вы писали:
P>Так а protected для кого придумали тогда.
Я же сказал: SYG>>4) Забудь про все остальное наследование, пользуйся только двух уровневым ИНТЕРФЕЙС -> РЕАЛИЗАЦИЯ.
и нету никакого protected-а. Когда придумывали protected, тогда до интерфейсов еще не додумались. Protected — это пережиток прошлого, так сказать "ложное направление развития ООП".
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>и нету никакого protected-а. Когда придумывали protected, тогда до интерфейсов еще не додумались. Protected — это пережиток прошлого, так сказать "ложное направление развития ООП".
Мне очень нравится internal protected (C#), а также package модификатор (Java). Очень полезные штуки для прятанья деталей.
