никогда не понимал конструкций вида

class Class1
{
  int  value;

   public:
     void SetValue(const int v) { value = v; }
     const int  GetValue(void) const { return value;}
};

    Class1 cl;
    cl.SetValue(1);

вопрос, а зачем такой изврат?

некоторые еще к большему маразму приходят

class Class1
{
   int _value;

   public:
    int &value(){ return _value; }
    const int value() const { return _value; }
};

вопрос, это такая религия? или это ООП головного мозга?

помоему сделать value в паблике, гараздо еффективнее
и не плодит избыточность кода

class Class1
{

   public:
    int  value;
};

  Class1 cl;
  cl.value = 1;

и код будет более читабельным при использовании

Здравствуйте, Аноним, Вы писали:

А>никогда не понимал конструкций вида
А>

А>class Class1
А>{
А>  int  value;

А>   public:
А>     void SetValue(const int v) { value = v; }
А>     const int  GetValue(void) const { return value;}
А>};

А>

А>  Class1 cl;
А>  cl.value = 1;
А>

А>и код будет более читабельным при использовании

А если ты в один прекрасный день захочешь при присваивании делать еще что-нибудь (проверять присваиваемое значение, записывать в лог) — будешь делать search/replace по 500000 строк кода?

Здравствуйте, Аноним, Вы писали:

А>помоему сделать value в паблике, гараздо еффективнее
А>и не плодит избыточность кода
А>

А>class Class1
А>{

А>   public:
А>    int  value;
А>};

ну тогда уж не class, а struct.
Вы очень примитивный пример привели. Ну не всегда же геттеры и сеттеры только и делают, что присваивают/возвращают значение. А если надо проверку какую-то сделать? А если этой проверки сначала и не предусматривалось а потом она появится?! ЧТо закрывать открытый мембер и дописывать геттер и сеттер? А если он сразу был написан, то только и надо будет, что поменять код этого сеттера и геттера.
Инкапсуляция однако.
Ещё один вариант тип передаваемого или возвращаемого значения не соответствует внутреннему типу переменной.

И вообще чем меньше окружающие знают о классе тем лучше, так что может проблема не в геттерах/сеттерах, а в архитектуре и эти геттеры/сеттеры вооьще не нужны?!

на первый взгляд это маразм на случай если вдруг
надо будет повесить дополнительное действие
на установку значения но если приспичило
можно __declspec(property) заюзать чисто msvc фишка

А>вопрос, это такая религия? или это ООП головного мозга?

класс должен предоставлять интерфейс для доступа к данным...

ЗЫ глянь pimpl

Здравствуйте, Аноним, Вы писали:

Кроме приведенных выше аргументов скажу еще один. Если у тебя программа валится из-за неправльной этой переменной, то с сеттером проще поймать кто её не правильной делает, поставив только один BreakPoint

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

А>>никогда не понимал конструкций вида
А>>

А>>class Class1
А>>{
А>>  int  value;

А>>   public:
А>>     void SetValue(const int v) { value = v; }
А>>     const int  GetValue(void) const { return value;}
А>>};

А>>

А>>  Class1 cl;
А>>  cl.value = 1;
А>>

А>>и код будет более читабельным при использовании

LP>А если ты в один прекрасный день захочешь при присваивании делать еще что-нибудь (проверять присваиваемое значение, записывать в лог) — будешь делать search/replace по 500000 строк кода?

Переводишь value из паблика в приват и компилятор тыкает тебя носом в каждую строчку, где value используется напрямую. Врядли таких строк будет так уж много.

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

LP>А если ты в один прекрасный день захочешь

Вот это и есть ООП головного мозга
Он же "overengineering".

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

ну и мои 5 коппек к приведенным аргументам "за":
0) если это достаточно сложный класс, у которого сложное внутренее состояние, то выставлять наружу одну поляну из десятка скрытых (уже имеющих не простые getterы и setterы) выглядит как-то глупо.

1) кроме того я стараюсь писать с параноидальными ассертами на все (входные параметры, в процессе и после выполнения какого-либо действия) -- т.е. ассертами в коде я стараюсь "документировать" все допущения которые я имею ввиду. и даже простые геттеры и сеттеры как правило содержат assertы проверяющие консистентность внутреннего состояния класса.

2) структуры без геттеров\сеттеров использую только для внутренних целей (т.е. когда структура не предназначена для публичного использования) или делаю структуры полностью без методов... например чтобы инкапсулировать -дцать параметров функции...

Здравствуйте, Аноним, Вы писали:


А>вопрос, это такая религия? или это ООП головного мозга?

А>помоему сделать value в паблике, гараздо еффективнее


толсто, бегом на двач.

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

M>Здравствуйте, los puercos, Вы писали:

А>>>никогда не понимал конструкций вида
А>>>

А>>>class Class1
А>>>{
А>>>  int  value;

А>>>   public:
А>>>     void SetValue(const int v) { value = v; }
А>>>     const int  GetValue(void) const { return value;}
А>>>};

А>>>

А>>>  Class1 cl;
А>>>  cl.value = 1;
А>>>

А>>>и код будет более читабельным при использовании

LP>>А если ты в один прекрасный день захочешь при присваивании делать еще что-нибудь (проверять присваиваемое значение, записывать в лог) — будешь делать search/replace по 500000 строк кода?

M>Переводишь value из паблика в приват и компилятор тыкает тебя носом в каждую строчку, где value используется напрямую. Врядли таких строк будет так уж много.

афигенно. и что дальше? делаешь ф-ию или копипастишь проверки?

Здравствуйте, Аноним, Вы писали:

...

Потому-что существует такое понятие как консистентность состояния, соответственно пред-условия и пост-условия. Assert-ы по всему коду разбрасывать будешь? А если правильность внутреннего состояния внезапно усложниться?

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

J>Вот это и есть ООП головного мозга
J>Он же "overengineering".

Поясни мысль пожалуйста. Чем плохо написать гетеры и сетеры? В плане читабельности cache.Size = 1000; на мой взгляд не отличается от cache.SetSize(1000); В плане быстродействия разницы никакой не будет. В плане трудоемкости, лично у меня займет секунд 10 написать гетер с сетером. Но имея написанные функции в случае чего я легко смогу добавить функционал, также функции будут удобней в отладке.

Здравствуйте, Аноним, Вы писали:

А>никогда не понимал конструкций вида
...
Многие много не понимают. Это нормально

А>вопрос, это такая религия? или это ООП головного мозга?

Нет не религия и не ООП головного мозга. Просто ООП. Причем очень мизерная и не самая сложная его часть.

А>помоему сделать value в паблике, гараздо еффективнее
А>и не плодит избыточность кода
...
А>и код будет более читабельным при использовании
Можно и так считать.
Но если в вакансии будет упомянуто ООП, лучше не шлите туда резюме,
а ежели пошлете — то не надо потом жаловаться что злые технари Ваш скил отвергли(или еще чего хуже)

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

LP>>>А если ты в один прекрасный день захочешь при присваивании делать еще что-нибудь (проверять присваиваемое значение, записывать в лог) — будешь делать search/replace по 500000 строк кода?

M>>Переводишь value из паблика в приват и компилятор тыкает тебя носом в каждую строчку, где value используется напрямую. Врядли таких строк будет так уж много.

B>афигенно. и что дальше? делаешь ф-ию или копипастишь проверки?

Зачем? Конечно, переведя value в приват, нужно сделать геттер/сеттер. А компилятор уже покажет места, где нужно будет подставить их вызовы вместо прямого обращения к полю.
ИМХО рефакторить код по мере надобности гораздо лучше, чем делать тривиальные аксессоры на каждое поле чисто на всякий случай или из каких-то суеверий типа "класс должен предоставлять интерфейс".
Разумеется без фанатизма — если сразу очевидно, что потребуется какое-то особое поведение при доступе к полю, то разумно сразу сделать заготовку аксессоров и вписать в них соответствующий to-do.
ИМХО пустые аксессоры в программе — это всё равно что неубранные леса на здании.

Здравствуйте, <Аноним>, Вы писали:

А>никогда не понимал конструкций вида
Ну, как вариант чтоб паходить все места в проге где переменная только меняется или только читается.
Если во время разработки есть планы на более сложную логику (проверки какие нибудь, или ещё что)

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

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

J>>Вот это и есть ООП головного мозга
J>>Он же "overengineering".

Ytz>Поясни мысль пожалуйста. Чем плохо написать гетеры и сетеры? В плане читабельности cache.Size = 1000; на мой взгляд не отличается от cache.SetSize(1000); В плане быстродействия разницы никакой не будет. В плане трудоемкости, лично у меня займет секунд 10 написать гетер с сетером. Но имея написанные функции в случае чего я легко смогу добавить функционал, также функции будут удобней в отладке.

Код cache.Size = 1000 не предполагает каких-либо действий кроме присваивания, а за cache.SetSize(1000) может скрываться, например, переаллкоация массива. Если код делает простые вещи, то он и выглядеть должен просто.

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

А>>помоему сделать value в паблике, гараздо еффективнее
А>>и не плодит избыточность кода
А>>

А>>class Class1
А>>{

А>>   public:
А>>    int  value;
А>>};

SM>ну тогда уж не class, а struct.
SM>Вы очень примитивный пример привели. Ну не всегда же геттеры и сеттеры только и делают, что присваивают/возвращают значение. А если надо проверку какую-то сделать? А если этой проверки сначала и не предусматривалось а потом она появится?! ЧТо закрывать открытый мембер и дописывать геттер и сеттер? А если он сразу был написан, то только и надо будет, что поменять код этого сеттера и геттера.

А если кто-то захочет использовать класс многопоточно? Давайте сразу каждый геттер и сеттер защищать мьютексом.

SM>Инкапсуляция однако.
SM>Ещё один вариант тип передаваемого или возвращаемого значения не соответствует внутреннему типу переменной.

SM>И вообще чем меньше окружающие знают о классе тем лучше, так что может проблема не в геттерах/сеттерах, а в архитектуре и эти геттеры/сеттеры вооьще не нужны?!

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

M>>Переводишь value из паблика в приват и компилятор тыкает тебя носом в каждую строчку, где value используется напрямую. Врядли таких строк будет так уж много.

B>афигенно. и что дальше? делаешь ф-ию или копипастишь проверки?

А вот это уже зависит. Вполне возможно, что изменившиеся требования, которые привели к невозможности использовать прямой доступ, привели бы к такиим же изменениям даже при наличии геттера-сеттера: за всю мою практику был лишь 1 (один) случай, когда мне пришлось перевести прямой доступ в геттер/сеттер. Один. Все остальные случаи требовали более серьезного изменения класса, который приводил к изчезновению этого члена из интерфейса вообще, что напрямую, что с геттером-сеттером, а вместо этого появлялись другие функции (а то и новые классы вместо старого), которые отвечали за новую функциональность.
Так что выгоды геттеров-сеттеров в качестве дизайн-паттерна по умолчанию по моему личному опыту — мифические.

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

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

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

J>>Вот это и есть ООП головного мозга
J>>Он же "overengineering".

Ytz>Поясни мысль пожалуйста. Чем плохо написать гетеры и сетеры? В плане читабельности cache.Size = 1000; на мой взгляд не отличается от cache.SetSize(1000); В плане быстродействия разницы никакой не будет. В плане трудоемкости, лично у меня займет секунд 10 написать гетер с сетером. Но имея написанные функции в случае чего я легко смогу добавить функционал, также функции будут удобней в отладке.

А еще бывают:

cache.Size += 1000;
cache.Size -= 1000;
cache.Size *= 1000;
cache.Size /= 1000;
cache.Size++;
++cache.Size;
cache.Size--;
--cache.Size;

void update_value(int&);
update_value( cache.Size );

успехов с геттерами-сеттерами.

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