Здравствуйте, Mishka, Вы писали:

M>Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>>и нету никакого protected-а. Когда придумывали protected, тогда до интерфейсов еще не додумались. Protected — это пережиток прошлого, так сказать "ложное направление развития ООП".

M>Мне очень нравится internal protected (C#), а также package модификатор (Java). Очень полезные штуки для прятанья деталей.

а можете объяснить что это за штуки?

Здравствуйте, korzhik, Вы писали:

K>а можете объяснить что это за штуки?

Модификаторы доступа в компонентно-ориентированном программировании.
Берёшь и пишешь:

Компонента 1

public class A
{
  protected internal void f(){}
}

public class B
{
  public void g()
  {
    A a = new A();
    a.f(); // доступ есть, поскольку объявлено как internal (внутренний)
  }
}

Компонента 2

public class С : A
{
  public void g()
  {
    f(); // доступ есть, поскольку объявлено как protected
  }
}

Очень полезно, когда на уровне компонента метод должен быть public, а для всего остального мира — protected.

pivoo -> "Re[6]: Применение protected-методов" :

hrg>> Ты библиотеку,которую будеь выкладывать/продавать/разное на
hrg>> сторону проектируешь или приложение, где видимость всех классов
hrg>> ясна?

p> А фиг его знает, по разному повернуться может.
p> Видимо все-таки вопрос не корректно задал, мне интересно было как
p> правильно делать, а не как сделать что бы всего лишь компилировалось
p> и работало в данный момент.

гавново... (зачеркнуто) это тоже просто: напиши цели проекта сюда, а мы тут
уж как нибудь

Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Пошло все на.... ]

Здравствуйте, hrg, Вы писали:

hrg>гавново... (зачеркнуто) это тоже просто: напиши цели проекта сюда, а мы тут
hrg>уж как нибудь

Вопрос не в целях проекта а в правильном проектировании
классов, хочется делать не тяп-ляп ...
чтобы не было мучительно больно за бесцельно прожитое время ...

pivoo -> "Re[8]: Применение protected-методов" :

hrg>> гавново... (зачеркнуто) это тоже просто: напиши цели проекта сюда,
hrg>> а мы тут уж как нибудь

p> Вопрос не в целях проекта а в правильном проектировании
p> классов, хочется делать не тяп-ляп ...
p> чтобы не было мучительно больно за бесцельно прожитое время ...

Ну как тебе сказать? Правильность, она бывает разная.

Yury Kopyl aka hrg | http://id.totem.ru |
"Хоббиты-маздай! Мордовия-фарева!" (С)Сарумян

p>> Вопрос не в целях проекта а в правильном проектировании
p>> классов, хочется делать не тяп-ляп ...
p>> чтобы не было мучительно больно за бесцельно прожитое время ...

Практика показала, что нужно писать код на чём-нибудь простом вроде C#, а не рисовать UML диаграммы. И использовать принцип минимализма.

Hello, Mishka!
You wrote on Fri, 30 Jul 2004 14:10:24 GMT:

p>>> Вопрос не в целях проекта а в правильном проектировании
p>>> классов, хочется делать не тяп-ляп ...
p>>> чтобы не было мучительно больно за бесцельно прожитое время ...

M> Практика показала, что нужно писать код на чём-нибудь простом вроде C#,
M> а не рисовать UML диаграммы. И использовать принцип минимализма.

Практика каждому свое показывает

With best regards, Sergey.

Здравствуйте, pivoo, Вы писали:

P>При проектировании классов какие должны быть предпосылки
P>к объявлению метода protected или private

Идея все спроектировать и спланировать заранее — использовалась у нас при коммунизме. Она вроде бы хорошая, но, как показала история, не работает
Поэтому, надо действовать иначе, а именно не принимать проектного решения до тех пор, пока не будешь в нем уверен на все 100%, иначе надо всячески оттягивать момент принятия такого решения. Как говориться: Не знаешь брода — не лезь в воду. Исходя из этого принципа, можно дать тебе рекомендацию:
1) если ты полностью уверен, что метод будет использоваться клиентами класса, делай его public
2) если ты полностью уверен, что метод будет использоваться потомками класса, делай его protected
3) все остальное делай private.

Логика тут простая: процедура понижения степени защиты метода занимает несколько секунд, а обратная процедура может потребовать переписывания большого количества кода. То есть цена ошибки гораздо выше. Делай выводы...

Здравствуйте, prVovik, Вы писали:

V>Идея все спроектировать и спланировать заранее — использовалась у нас при коммунизме. Она вроде бы хорошая, но, как показала история, не работает
Планирование — залог успеха проекта, пренебрежение им — залог провала. И СССР тут не при чем.

V>Поэтому, надо действовать иначе, а именно не принимать проектного решения до тех пор, пока не будешь в нем уверен на все 100%, иначе надо всячески оттягивать момент принятия такого решения.
Если у вас в объектной модели 2-3 сотни классов, в каждом из которых имеются какие-то оттянутые (непринятые) решения, то это 100% приведет к срыву сроков, так как это ведет к взрывному росту сложности и количества деталей, необходимых держать в голове (т.е. количеству неотъемлемых знаний, за которыми скрываются незаменимые люди, что в свою очередь, всегда зло).

Вообще пуристский (самый правильный, но обычно трудно реализуемый :) подход изложил S.Yu.Gubanov, но в несколько категоричной форме, и кажется перепутал причину и следствие . Причина — это то, что наследование реализации = в целом есть зло, так как кроет в себе опасность, не видимую на первый взгляд, но которая, если по-хорошему, приводит к серьезному удару по low coupling и testability, так как принуждает при реализации потомков делать какие-то заключения о _реализации_ предка. Пример:

class B
{
public:
   int public_op()
   {
      return real_op1();
   }

protected:
   virtual int real_op1()
   {
       return real_op2();
   }
   virtual int real_op2()
   {
      return 1;
   }
};

class C : public B
{
protected:
   virtual int real_op2()
   {
      return real_op1();
   }
}

Код корректный. Класс B — корректный, класс C — корректный, но вот при выполнении слдедующего кода (тоже корректного), использующего нашу модель:

   C c;
   c.public_op();

Мы воткнемся в stack overflow. Почему? Классы C и B связаны более жестко, чем это может показаться.

Так вот после признания наследования реализации злом, мы приходим к выводу, что protected — тоже зло, так как без наследования реализации такой модификатор ни к чему . Идея в общем-то здоровая и сильно упрощающая модель, поддержку и тестирование, но обячно менее продуктивна.

Теперь о protected. Мое мнение заключается в том, что как protected надо объявлять методы реализации, облегченные для доверительного вызывающего кода (т.е. наследников и friend'ов). Облегченные, например, в смысле отсутствия проверки на входные параметры или не публикующие исключения. То есть:

class B
{
public:
   void public_op(int p1, int p2, void* p3)
   {
      // делаем проверку аргументов
      if (p1 > 1 || p2 <100 || p3 == NULL)
         throw invalid_argument("f.u.");

      // ловим исключения, чтобы их потом опубликовать (например сообщением пользователю!)
      try
      {
         real_op(p1, p2, p3);
      }
      catch (std::exception e)
      {
         exception_publisher::instance().publish(e);
      }

   }
protected:
      void real_op(int p1, int p2, void* p3)
      {
          // а тут уже реализация без проверки и публикации
      }
}

Тогда, реализуя "class C : public B" мы можем использовать более быструю реализацию op (real_op), так как сами уже будем проверять передаваемые параметры и сами будем публиковать исключения, если это потребуется.

В других ситуациях:

• "в базе есть кусок красивый кусок кода, который так и хочется вызвать из потомков",
  
• "в базе есть метод, побочный эффект которого очень хорошо меняет состояние объекта",
  
• "да в базе это уже реализовано, только вот тут надо if'чик воткнуть, а тут подтереть, да дат подписать"
  
• и т.п. "удобности" и ложные упрощения,

использование protected неоправданно и следует либо выделять метод, в том числе статический, либо выделять класс, в том числе внутренний для базы protected хелпер, который использовать уже в безопасной манере.

V>Логика тут простая: процедура понижения степени защиты метода занимает несколько секунд, а обратная процедура может потребовать переписывания большого количества кода.
А тесты и спецификации переписывать уже непринято? Ведь изменения видимости метода класса — это огромное изменение модели, поэтому потребуется переписать массу тестов, чтобы протестировать получение объектом нового публичного сообщения в каждом из его состояний.

Здравствуйте, Frostbitten, Вы писали:

F>Планирование — залог успеха проекта, пренебрежение им — залог провала. И СССР тут не при чем.
Это, конечно, правильно, но только не стоит слишком полагаться на планирование. Дело тут вот в чем. Планирование хорошо тогда, когда оно безошибочно. А это утопия Поэтому, я считаю, что лучше отложить смутное архитектурное решение на потом, чем допустить в нем ошибку, особенно на ранней стадии. Откладывая решение, мы, таким образом, не отказываемся от планирования, но, зато, оберегаемся от архитектурных ошибок.

>Если у вас в объектной модели 2-3 сотни классов, в каждом из которых имеются какие-то оттянутые (непринятые) решения, то это 100% приведет к срыву сроков, так как это ведет к взрывному росту сложности и количества деталей, необходимых держать в голове (т.е. количеству неотъемлемых знаний, за которыми скрываются незаменимые люди, что в свою очередь, всегда зло).
Не очень понял о чем это вы? Что за сложность и какие такие детали надо держать в голове?

>спецификации переписывать уже непринято?
Автоматизированные системы построения документации спасут...

>Ведь изменения видимости метода класса — это огромное изменение модели, поэтому потребуется переписать массу тестов, чтобы протестировать получение объектом нового публичного сообщения в каждом из его состояний.
Ну а что мешает написать тест для закрытого метода, особенно, если он делает что-то осмысленное?

Здравствуйте, Frostbitten, Вы писали:

F>Планирование — залог успеха проекта, пренебрежение им — залог провала. И СССР тут не при чем.

Есть такая поговорка:
"If you fail to plan, you plan to fail"
Провал планирования — это планирование провала

Здравствуйте, pivoo, Вы писали:

P>Здравствуйте, hrg, Вы писали:

hrg>>гавново... (зачеркнуто) это тоже просто: напиши цели проекта сюда, а мы тут
hrg>>уж как нибудь

P>Вопрос не в целях проекта а в правильном проектировании
P>классов, хочется делать не тяп-ляп ...
P>чтобы не было мучительно больно за бесцельно прожитое время ...
Это явно по-молодости.
Один из военных законов Мэрфи: Если это глупо, но работает — значит, это не глупо.
В общем абсолютной истины (то бишь, правильности) — нет. Как напишешь, так и будет правильно. Если, конечно, специально лабуду всякую писать не будешь.

Sergey -> "Re[11]: Применение protected-методов" :

p>>>> Вопрос не в целях проекта а в правильном проектировании
p>>>> классов, хочется делать не тяп-ляп ...
p>>>> чтобы не было мучительно больно за бесцельно прожитое время ...

M>> Практика показала, что нужно писать код на чём-нибудь простом вроде
M>> C#, а не рисовать UML диаграммы. И использовать принцип минимализма.

S> Практика каждому свое показывает

Хочешь поговрить об этом?

Yury Kopyl aka hrg | http://id.totem.ru | "Спам придумали боги в отместку
за наши молитвы."

Здравствуйте, pivoo, Вы писали:

P>При проектировании классов какие должны быть предпосылки
P>к объявлению метода protected или private

P>Мне кажется, что методы которые специфичны для конкретно
P>этого класса должны объявляться private, а остальные, но
P>которые не должны быть public должны объявляться protected.

P>Корректно сформулировать вопрос не удалось, но надеюсь
P>вы меня поняли.

P>Правильно ли я думаю?

То, что не может быть открыто внешним клиентам класса, не должно объявляться public.
То из оставшегося, что не может быть открыто наследникам класса, должно объявляться private.
Остальное — protected.

You will always get what you always got
  If you always do  what you always did