доступ к мемберам класса(getter'ы и setter'ы)
От: Аноним  
Дата: 02.03.11 11:39
Оценка: +1 -1 :))) :)))
никогда не понимал конструкций вида
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;

и код будет более читабельным при использовании
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: los puercos  
Дата: 02.03.11 11:59
Оценка: 1 (1) -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 строк кода?
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: SullenMan  
Дата: 02.03.11 12:00
Оценка: +3
Здравствуйте, Аноним, Вы писали:

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

А>и не плодит избыточность кода
А>
А>class Class1
А>{

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


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

И вообще чем меньше окружающие знают о классе тем лучше, так что может проблема не в геттерах/сеттерах, а в архитектуре и эти геттеры/сеттеры вооьще не нужны?!
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: jyuyjiyuijyu  
Дата: 02.03.11 12:02
Оценка:
на первый взгляд это маразм на случай если вдруг
надо будет повесить дополнительное действие
на установку значения но если приспичило
можно __declspec(property) заюзать чисто msvc фишка
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: LameFox Россия http://vectools.com
Дата: 02.03.11 12:16
Оценка:
А>вопрос, это такая религия? или это ООП головного мозга?

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

ЗЫ глянь pimpl
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: Anpek  
Дата: 02.03.11 12:43
Оценка: +1
Здравствуйте, Аноним, Вы писали:

Кроме приведенных выше аргументов скажу еще один. Если у тебя программа валится из-за неправльной этой переменной, то с сеттером проще поймать кто её не правильной делает, поставив только один BreakPoint
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 02.03.11 12:53
Оценка: +1 -3 :)
Здравствуйте, 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 используется напрямую. Врядли таких строк будет так уж много.
Главное гармония ...
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 02.03.11 12:55
Оценка: +6 -5
Здравствуйте, los puercos, Вы писали:

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

Вот это и есть ООП головного мозга
Он же "overengineering".
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: zaufi Земля  
Дата: 02.03.11 15:22
Оценка:
ну и мои 5 коппек к приведенным аргументам "за":
0) если это достаточно сложный класс, у которого сложное внутренее состояние, то выставлять наружу одну поляну из десятка скрытых (уже имеющих не простые getterы и setterы) выглядит как-то глупо.

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

2) структуры без геттеров\сеттеров использую только для внутренних целей (т.е. когда структура не предназначена для публичного использования) или делаю структуры полностью без методов... например чтобы инкапсулировать -дцать параметров функции...
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: blackhearted Украина  
Дата: 02.03.11 15:58
Оценка: 1 (1) +1
Здравствуйте, Аноним, Вы писали:


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


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



толсто, бегом на двач.
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: blackhearted Украина  
Дата: 02.03.11 15:59
Оценка:
Здравствуйте, 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 используется напрямую. Врядли таких строк будет так уж много.


афигенно. и что дальше? делаешь ф-ию или копипастишь проверки?
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: AcidTheProgrammer Россия https://hts.tv/
Дата: 02.03.11 16:07
Оценка:
Здравствуйте, Аноним, Вы писали:

...


Потому-что существует такое понятие как консистентность состояния, соответственно пред-условия и пост-условия. Assert-ы по всему коду разбрасывать будешь? А если правильность внутреннего состояния внезапно усложниться?
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 02.03.11 18:25
Оценка:
Здравствуйте, jazzer, Вы писали:

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

J>Он же "overengineering".

Поясни мысль пожалуйста. Чем плохо написать гетеры и сетеры? В плане читабельности cache.Size = 1000; на мой взгляд не отличается от cache.SetSize(1000); В плане быстродействия разницы никакой не будет. В плане трудоемкости, лично у меня займет секунд 10 написать гетер с сетером. Но имея написанные функции в случае чего я легко смогу добавить функционал, также функции будут удобней в отладке.
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: robin_of_the_wood Россия  
Дата: 02.03.11 18:52
Оценка: -1
Здравствуйте, Аноним, Вы писали:

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

...
Многие много не понимают. Это нормально

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


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

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

А>и не плодит избыточность кода
...
А>и код будет более читабельным при использовании
Можно и так считать.
Но если в вакансии будет упомянуто ООП, лучше не шлите туда резюме,
а ежели пошлете — то не надо потом жаловаться что злые технари Ваш скил отвергли(или еще чего хуже)
Проектирование велосипедов для слепых жирафов
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 02.03.11 20:45
Оценка: +4
Здравствуйте, blackhearted, Вы писали:

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


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


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


Зачем? Конечно, переведя value в приват, нужно сделать геттер/сеттер. А компилятор уже покажет места, где нужно будет подставить их вызовы вместо прямого обращения к полю.
ИМХО рефакторить код по мере надобности гораздо лучше, чем делать тривиальные аксессоры на каждое поле чисто на всякий случай или из каких-то суеверий типа "класс должен предоставлять интерфейс".
Разумеется без фанатизма — если сразу очевидно, что потребуется какое-то особое поведение при доступе к полю, то разумно сразу сделать заготовку аксессоров и вписать в них соответствующий to-do.
ИМХО пустые аксессоры в программе — это всё равно что неубранные леса на здании.
Главное гармония ...
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: CreatorCray  
Дата: 02.03.11 20:46
Оценка:
Здравствуйте, <Аноним>, Вы писали:

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

Ну, как вариант чтоб паходить все места в проге где переменная только меняется или только читается.
Если во время разработки есть планы на более сложную логику (проверки какие нибудь, или ещё что)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 02.03.11 20:49
Оценка: +1
Здравствуйте, Ytz, Вы писали:

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


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

J>>Он же "overengineering".

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


Код cache.Size = 1000 не предполагает каких-либо действий кроме присваивания, а за cache.SetSize(1000) может скрываться, например, переаллкоация массива. Если код делает простые вещи, то он и выглядеть должен просто.
Главное гармония ...
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 02.03.11 20:53
Оценка: 1 (1) +1
Здравствуйте, SullenMan, Вы писали:

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

А>>и не плодит избыточность кода
А>>
А>>class Class1
А>>{

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


SM>ну тогда уж не class, а struct.

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

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

SM>Инкапсуляция однако.

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

SM>И вообще чем меньше окружающие знают о классе тем лучше, так что может проблема не в геттерах/сеттерах, а в архитектуре и эти геттеры/сеттеры вооьще не нужны?!
Главное гармония ...
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 02.03.11 22:06
Оценка: 2 (1) +4
Здравствуйте, blackhearted, Вы писали:

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


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


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

You will always get what you always got
  If you always do  what you always did
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 02.03.11 22:10
Оценка: 9 (1) +1
Здравствуйте, 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 );

успехов с геттерами-сеттерами.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: LameFox Россия http://vectools.com
Дата: 02.03.11 22:37
Оценка: 1 (1) +2
Здравствуйте, jazzer, Вы писали:
J>cache.Size += 1000;
J>cache.Size -= 1000;
J>cache.Size *= 1000;
J>cache.Size /= 1000;


...
cache.size = 1000;
...
...
cache.size -= 1001;
...
...
и что дальше ?
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: MasterZiv СССР  
Дата: 03.03.11 00:20
Оценка:
On 02.03.2011 14:39, Аноним 325 wrote:

> public:

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

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


Семантически смысла в таком коде нет никакого.
Технически обычно так делают с закладом на будущее,
что в будущем код может быть изменён, и логика SetValue
будет гораздо сложнее (и реализована не инлайнеров в хэдере).
Так код клиентов класса не нужно будет менять.
Posted via RSDN NNTP Server 2.1 beta
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: c-smile Канада http://terrainformatica.com
Дата: 03.03.11 04:48
Оценка: +2
Здравствуйте, LameFox, Вы писали:

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


Кому должен?

LF>ЗЫ глянь pimpl


Зачем?
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: c-smile Канада http://terrainformatica.com
Дата: 03.03.11 04:52
Оценка: 1 (1) +2
Здравствуйте, Anpek, Вы писали:

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


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


Ерунда какая ... За для дебага вносить потенциальную неоптимальность.

Если надо break point ставить то нарисуй себе что-то типа этого и будет тебе милай шастя:

template<typename T> 
  struct accessor
  {
    T data;
    accessor& operator=(T t) { data = t; return *this; }
    operator T() const { return data; }
  };

struct zoo 
{
  int foo;
  accessor<int> bar;
};

int main(int argc, char* argv[])
{
  zoo z;
  z.foo = 220;
  z.bar = 110;

  std::cout << z.foo << " " << z.bar;
  
    return 0;
}
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: night beast СССР  
Дата: 03.03.11 05:36
Оценка:
Здравствуйте, zaufi, Вы писали:

Z>ну и мои 5 коппек к приведенным аргументам "за":


а как тогда правильно должен выглядеть std::pair?
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: ibnhatab Украина  
Дата: 03.03.11 06:07
Оценка: +1
Здравствуйте, Аноним, Вы писали:

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

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

Код конечно будет проще, но "ООП головного мозга" как ты выразился не всегда плохо.

Отсутствие геттеров/сеттеров несет в себе проблему возможности нарушения инварианты класса, что грубо говоря означает установка значения которого там быть не должно по контракту. Идеальный вариант когда можно обойтись без геттеров/сеттеров, это когда состояние объекта задается в конструкторе и не меняется на протяжении жизни экземпляра. Но это уже вариации на тему ФП в С++ и может называться "ФП головного мозга" .

Убрав геттер/сеттер мы получим что то из разряда процедурного программирования, что не есть плохо, но тогда проблемы надо будет решать хорошей документацией (и чем больше таких полей с четко ограниченными значениями тем больше документации надо писать). Используя геттеры и сеттеры обработку проблемы сохранения инварианты можно переложить именно на них.

Плюс для себя выработал такое правило: класс должен выглядеть однообразно — то есть если в нем нужны геттеры/сеттеры то лучше все поля выставлять через них, иначе можно все делать открытыми.
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 03.03.11 06:37
Оценка: -1
Здравствуйте, jazzer, Вы писали:

J>А еще бывают:

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

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

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

Я понял — ради небольшого удобства открываем дыру в защите.
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 03.03.11 06:39
Оценка:
Здравствуйте, c-smile, Вы писали:

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


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


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


CS>Ерунда какая ... За для дебага вносить потенциальную неоптимальность.


А правда есть компилятор который не встроит простой геттер-сеттер? Понятно, при условии, что нет указателя на данную функцию.
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: zaufi Земля  
Дата: 03.03.11 06:53
Оценка: +1
Здравствуйте, night beast, Вы писали:

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


Z>>ну и мои 5 коппек к приведенным аргументам "за":


NB>а как тогда правильно должен выглядеть std::pair?

а что с ним??
пабликовая структура без методов... ничего больше не надо...
std::pair -- типичная служебная структура без особой смысловой нагрузки
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 03.03.11 08:03
Оценка:
Здравствуйте, Anpek, Вы писали:

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


Для этого есть data breakpoint's.
Главное гармония ...
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: sidorov18 США  
Дата: 03.03.11 08:15
Оценка:
Здравствуйте, Anpek, Вы писали:

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


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


В Студии есть break point на изменение памяти.

Хотя в целом скорее положительный аргумент можно поставить:

void setter(int value)
{
   assert(value == 123);
   m_value = value;
}


Но минус тоже есть — небольшое неудобство, когда отлаживаешь код, и есть вызов функции:

void func( int value )
{
}

func( my.getValue() );


Приходится либо заходить в гетер, либо открывать файл с функцией и ставить там брейкпоинт, что бы не заходить в ненужные функции
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 03.03.11 09:11
Оценка:
Здравствуйте, LameFox, Вы писали:

LF>и что дальше ?

Это к чему все было?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 03.03.11 09:21
Оценка:
Здравствуйте, Ytz, Вы писали:

Ytz>Я понял — ради небольшого удобства открываем дыру в защите.


А, ну да, надо наоборот — ради воображаемой защиты от воображаемой опасности делаем работу с классом неудобной и неоптимальной, а код — нечитабельным.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: c-smile Канада http://terrainformatica.com
Дата: 03.03.11 17:35
Оценка:
Здравствуйте, Ytz, Вы писали:

CS>>Ерунда какая ... За для дебага вносить потенциальную неоптимальность.


Ytz>А правда есть компилятор который не встроит простой геттер-сеттер? Понятно, при условии, что нет указателя на данную функцию.


См. /Ob0 например здесь:
http://msdn.microsoft.com/en-us/library/47238hez(v=vs.71).aspx

/Ob0 — Disables inline expansion, which is on by default.


Т.е. если ты не знаешь в чьи руки твой код попадет то лучше свои намерения выражать явно.
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: los puercos  
Дата: 04.03.11 07:42
Оценка:
Здравствуйте, jazzer, Вы писали:

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

J>Так что выгоды геттеров-сеттеров в качестве дизайн-паттерна по умолчанию по моему личному опыту — мифические.

Максим, при всем уважении к вашему опыту — это не более чем ваш личный опыт. Мой же опыт подсказывает, что ассерты в сеттерах _очень_ помогают на этапе отладки.
А рез есть сеттер — почему бы для единообразия не добавить геттер?
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 04.03.11 08:34
Оценка: +2
Здравствуйте, los puercos, Вы писали:

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


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

J>>Так что выгоды геттеров-сеттеров в качестве дизайн-паттерна по умолчанию по моему личному опыту — мифические.

LP>Максим, при всем уважении к вашему опыту — это не более чем ваш личный опыт.

Ну, это не просто мой личный опыт (в своих проектах я не делаю геттеров/сеттеров по умолчанию), это опыт больших промышленных проектов, в которых я участвовал.

LP>Мой же опыт подсказывает, что ассерты в сеттерах _очень_ помогают на этапе отладки.

LP>А рез есть сеттер — почему бы для единообразия не добавить геттер?

Это опыт отладки, тут более естественно использовать data breakpoints, как уже кто-то указал.
Потому что от изменения этой же переменной изнутри самого класса (а это уже не через сеттер, естественно) так не отловить, не говоря уже о том, что не отловить пробежку по памяти — а это самая частая причина странных и неожиданных значений, равно как и просто неинициализированная память — тут тоже сеттеры и ассерты в них не помогут.

Есть ли реальный опыт добавления функциональности в сеттеры, чтоб эта функциональность не подразумевалась сразу же, а, как тут предлагается, сеттеры были сделаны в самлм начале просто на всякий случай?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 04.03.11 08:35
Оценка:
Здравствуйте, jazzer, Вы писали:

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


LF>>и что дальше ?

J>Это к чему все было?

К тому, что надо срочно все сеттеры с ассертами убрать, а не то, не дай бог багу поймаем.
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 04.03.11 09:55
Оценка:
Здравствуйте, Ytz, Вы писали:

LF>>>и что дальше ?

J>>Это к чему все было?

Ytz>К тому, что надо срочно все сеттеры с ассертами убрать, а не то, не дай бог багу поймаем.

Как-то это было очень завуалировано. Это, наверное, как раз был пример такой Неуловимой Баги
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: los puercos  
Дата: 04.03.11 10:08
Оценка:
Здравствуйте, jazzer, Вы писали:

LP>>Максим, при всем уважении к вашему опыту — это не более чем ваш личный опыт.

J>Ну, это не просто мой личный опыт (в своих проектах я не делаю геттеров/сеттеров по умолчанию), это опыт больших промышленных проектов, в которых я участвовал.

LP>>Мой же опыт подсказывает, что ассерты в сеттерах _очень_ помогают на этапе отладки.

LP>>А рез есть сеттер — почему бы для единообразия не добавить геттер?

J>Это опыт отладки, тут более естественно использовать data breakpoints, как уже кто-то указал.

Возможно. Я привык использовать assert — это банально быстрее и удобнее.

J>Потому что от изменения этой же переменной изнутри самого класса (а это уже не через сеттер, естественно) так не отловить, не говоря уже о том, что не отловить пробежку по памяти — а это самая частая причина странных и неожиданных значений, равно как и просто неинициализированная память — тут тоже сеттеры и ассерты в них не помогут.

Кхм... А что такое "пробежка по памяти"?

J>Есть ли реальный опыт добавления функциональности в сеттеры, чтоб эта функциональность не подразумевалась сразу же, а, как тут предлагается, сеттеры были сделаны в самлм начале просто на всякий случай?

Нет, но есть неоднократный опыт занесения паблик-переменных в сеттер с проверкой после очередного отлова некорректного присвоения где-нибудь в недрах проекта в полмиллиона строк.
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 04.03.11 10:46
Оценка:
Здравствуйте, los puercos, Вы писали:

J>>Это опыт отладки, тут более естественно использовать data breakpoints, как уже кто-то указал.

LP>Возможно. Я привык использовать assert — это банально быстрее и удобнее.
Ну если приоритет — отладка, то тогда конечно.
Но для меня это — недостаточная причина, чтобы писать
std::vector<HeavyObject> temp = o.get_v();
temp.sort();
o.set_v( temp );

вместо
o.v.sort();


J>>Потому что от изменения этой же переменной изнутри самого класса (а это уже не через сеттер, естественно) так не отловить, не говоря уже о том, что не отловить пробежку по памяти — а это самая частая причина странных и неожиданных значений, равно как и просто неинициализированная память — тут тоже сеттеры и ассерты в них не помогут.

LP>Кхм... А что такое "пробежка по памяти"?
Она же "расстрел памяти", она же "стрельба по памяти". Запись по левому указателю, короче.

J>>Есть ли реальный опыт добавления функциональности в сеттеры, чтоб эта функциональность не подразумевалась сразу же, а, как тут предлагается, сеттеры были сделаны в самлм начале просто на всякий случай?

LP>Нет, но есть неоднократный опыт занесения паблик-переменных в сеттер с проверкой после очередного отлова некорректного присвоения где-нибудь в недрах проекта в полмиллиона строк.
Ну т.е. пока что use cases сводятся к ассертам, а по мифической дополнительной функциональности, которая вдруг может понадобиться, у нас опыт совпадает.
Ну даже если так, и у тебя проверка на, скажем, диапазон.
И есть проблемный код, который пихает туда неправильное значение.
Согласись, что неправильное значение легко может попасть в диапазон правильных значениий и при этом оставаться неправильным?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: доступ к мемберам класса(getter'ы и setter'ы)
От: LameFox Россия http://vectools.com
Дата: 04.03.11 12:41
Оценка: 2 (2)
Здравствуйте, jazzer, Вы писали:

J>
J>o.v.sort();
J>


Не, лучше так:

o.sort();



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

J>Согласись, что неправильное значение легко может попасть в диапазон правильных значениий и при этом оставаться неправильным?

Если "v" скрыть, и определить интерфейс доступа к значениям, то ничего лишнего никуда не попадет и не откуда не пропадет.
Re[10]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 04.03.11 13:02
Оценка: 1 (1)
Здравствуйте, LameFox, Вы писали:

LF>Если "v" скрыть, и определить интерфейс доступа к значениям, то ничего лишнего никуда не попадет и не откуда не пропадет.

о чем я и говорю. Сеттеры-геттеры — не вариант.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[9]: доступ к мемберам класса(getter'ы и setter'ы)
От: LameFox Россия http://vectools.com
Дата: 04.03.11 13:07
Оценка:
J>вместо
J>
J>o.v.sort();
J>


Не совсем понятно, например, если "v" содержит возрастные данные,
то можно легко гденить (и даже не по злому умыслу) запихнуть отрицательное значение..
и получить в отчете:

"Вася Пупкин ........ -100 лет"

или прокалькулировать:

"Вычисленная продолжительность жизни по предложенной диете....-1 год"

и т.п.

и допустим, в коде таких манипуляций со списком — много...
и будет это выглядеть вышепредложенным способом, типа:

o.v.sort();
o.v.insert(i, age);
....
и т.п.

как решить описанную ситуацию ?
Куда воткнуть в коде брекпойнт, для проверки валидности сохраненяемых значений ?
Re[10]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 04.03.11 13:23
Оценка:
Здравствуйте, LameFox, Вы писали:

LF>Не совсем понятно, например, если "v" содержит возрастные данные,


std::vector<Age> v;

Age сам должен следить за своей неотрицательностью.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 04.03.11 13:33
Оценка:
Здравствуйте, jazzer, Вы писали:

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


LF>>Не совсем понятно, например, если "v" содержит возрастные данные,


J>std::vector<Age> v;


J>Age сам должен следить за своей неотрицательностью.


То есть ты уже стал сам себе противоречить?


class Age
{
public:
    Age(unsigned);

    unsigned Get() const;
    void Set(unsigned);

private:
    unsigned Age_;
};



Так ведь? Иначе как ты проверишь корректность устанавливаемых значений?
Re[11]: доступ к мемберам класса(getter'ы и setter'ы)
От: LameFox Россия http://vectools.com
Дата: 04.03.11 13:36
Оценка:
J>std::vector<Age> v;

J>Age сам должен следить за своей неотрицательностью.


отлично!

если надо посчитать количество годков в неком тесте, то следуя логике "без сеттеров":

Person person("Вася", "Пупкин");
Age age(25);

......

age.value -= 15; // если пьет

......

age.value -= 15; // если курит

......

age.value -= 15; // если много сидит перед компьютером

.......

age.value += 10; // если занимаетца физкультурой

и т.п.

......

//
// косяки
//
person.age = age;

report.v.append(age);


Где следить за значением ?
Re[12]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 04.03.11 14:43
Оценка: +1
Здравствуйте, Ytz, Вы писали:

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


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


LF>>>Не совсем понятно, например, если "v" содержит возрастные данные,


J>>std::vector<Age> v;


J>>Age сам должен следить за своей неотрицательностью.


Ytz>То есть ты уже стал сам себе противоречить?


Где противоречие?
Я против геттеров-сеттеров по умолчанию, когда еще неизвестно, будет ли какая-нибудь дополнительная функциональность.
И спорю я с тезисом "А вот в один прекрасный день..."

А здесь у нас не прекрасный день, здесь с самого начало известно, что надо что-то делать.
В таких случаях я ничего против геттеров-сеттеров не имел и не имею.

А вот если у тебя в классе был массив интов, а потом вдруг "в один прекрасный день" выяснилось, что это массив возрастов... такое в реальной жизни часто бывает? Мне вот не встречалось
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: доступ к мемберам класса(getter'ы и setter'ы)
От: CreatorCray  
Дата: 04.03.11 14:45
Оценка:
Здравствуйте, LameFox, Вы писали:

LF>Не, лучше так:

LF>
LF>o.sort_v();
LF>o.sort_w();
LF>o.sort_x();
LF>o.sort_y();
LF>o.sort_z();
...
LF>


Т.е. к каждой переменной надо ещё и sort и все остальные inplace алгоритмы приделывать, которые могут понадобится?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 04.03.11 14:48
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Где противоречие?

J>Я против геттеров-сеттеров по умолчанию, когда еще неизвестно, будет ли какая-нибудь дополнительная функциональность.
J>И спорю я с тезисом "А вот в один прекрасный день..."

J>А здесь у нас не прекрасный день, здесь с самого начало известно, что надо что-то делать.

J>В таких случаях я ничего против геттеров-сеттеров не имел и не имею.

J>А вот если у тебя в классе был массив интов, а потом вдруг "в один прекрасный день" выяснилось, что это массив возрастов... такое в реальной жизни часто бывает? Мне вот не встречалось


Вот теперь понял, возражений нет
Re: кодогенерация, есть ли?
От: Temnikov Россия  
Дата: 05.03.11 07:40
Оценка:
А есть ли возможность генерировать автоматически:
     void SetValue(const int v) { value = v; }
     const int  GetValue(void) const { return value;}


Сам обычно пользуюсь макросами, но иногда надо разворачивать код(условие проверить или алгоритм сеттера не тривиальный) и все равно вручную печатать данные функции.
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: trans  
Дата: 05.03.11 08:51
Оценка:
Такой код

c.value = 1;


время съэкономит сейчас.
А такой

с.SetValue( 1 );


потом и, как показывает практика, многократно.

Первый подход можно использовать в тех случаях, когда требуется выдать результат для продажи как можно быстрее.
Второй — для долгосрочных проектов.
Re[11]: доступ к мемберам класса(getter'ы и setter'ы)
От: MasterZiv СССР  
Дата: 05.03.11 09:20
Оценка:
On 04.03.2011 16:02, jazzer wrote:

> LF>Если "v" скрыть, и определить интерфейс доступа к значениям, то ничего

> лишнего никуда не попадет и не откуда не пропадет.
> о чем я и говорю. Сеттеры-геттеры — не вариант.

Ещё кстати вспомнил, когда это нужно.
Если реализуются в какой-то системе property, типа как в QT,
и проперти эти требуют наличия указателей на функции (что более логично,
чем на данные).
Posted via RSDN NNTP Server 2.1 beta
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: sokel Россия  
Дата: 05.03.11 09:33
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Так что выгоды геттеров-сеттеров в качестве дизайн-паттерна по умолчанию по моему личному опыту — мифические.


Я тоже так думал когда то. Структуры + методы. Но тот же личный опыт всё таки подсказывает что это не очень правильно. Местами конечно можно, но обычно такой подход чреват печальными последствиями. Структуры имеют свойство разрастаться. Код, меняющий данные, расплывается по проекту. Со временем становится всё трудней определять "в каком же месте это значение устанавливаетя". Использование аксессоров дает такой бонус, как простота отслеживания доступа на запись. Зачастую сеттеры вообще бывают не нужны, все значения могут устанавливаться в каком нибудь одном методе вроде конструктора или ф-ции initialize (ну или не все значения, но по крайней мере связные группы точно). Убрал всё в приват и можешь быть уверен, что просто так изменить данные никто не сможет, инкапсуляция — великая вещь. Ну и просто некрасиво выглядит доступ, если имена членов как либо синтаксически выделены, конструкции вида object.member_ = xxx режут глаз. Метод, использующий большое количество сеттеров намекает на возможность рефакторинга в виде переноса кода в метод класса.
Ортогонализация рулит, а аксессоры — способ следования правилу Деметры. А в соседнем посте приведён явный пример того, во что может превратиться код если ему не следовать:
Accept->getVectorConnections()[NumberInVectorConnections[i]].getFirstRecvPacket().Buff
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 05.03.11 10:35
Оценка:
Здравствуйте, sokel, Вы писали:

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


J>>Так что выгоды геттеров-сеттеров в качестве дизайн-паттерна по умолчанию по моему личному опыту — мифические.


S>Я тоже так думал когда то. Структуры + методы. Но тот же личный опыт всё таки подсказывает что это не очень правильно. Местами конечно можно, но обычно такой подход чреват печальными последствиями. Структуры имеют свойство разрастаться. Код, меняющий данные, расплывается по проекту.

S>Со временем становится всё трудней определять "в каком же месте это значение устанавливаетя". Использование аксессоров дает такой бонус, как простота отслеживания доступа на запись.
Для этого есть data breakpoints.
S>Зачастую сеттеры вообще бывают не нужны, все значения могут устанавливаться в каком нибудь одном методе вроде конструктора или ф-ции initialize (ну или не все значения, но по крайней мере связные группы точно).
Функция initialize это плохо.
S>Убрал всё в приват и можешь быть уверен, что просто так изменить данные никто не сможет, инкапсуляция — великая вещь.
Угу. А методы класса об этом и не знают. Потому что для обеспечения константности используют модификатор константности, а не область видимости private.
S> Ну и просто некрасиво выглядит доступ, если имена членов как либо синтаксически выделены, конструкции вида object.member_ = xxx режут глаз.
Так называй поля не member_ а member.
S> Метод, использующий большое количество сеттеров намекает на возможность рефакторинга в виде переноса кода в метод класса.
Угу. А потом искать место изменения переменной установкой брекпоинта в сеттере

S>Ортогонализация рулит, а аксессоры — способ следования правилу Деметры. А в соседнем посте приведён явный пример того, во что может превратиться код если ему не следовать:

S>
S>Accept->getVectorConnections()[NumberInVectorConnections[i]].getFirstRecvPacket().Buff
S>

Здесь мы видим два геттера и один прямой доступ к полю. Аааатличный пример того, нарушать правило Деметры можно и так, и эдак.
Ещё очень интересно посмотреть, что же возвращает метод getVectorConnections().

А ещё очень милые ситуации возникают, когда требуется адрес переменной вместо её значения, например для отложенной модификации:
Point p;
scanf("%d;%d", p.x, p.y);

vs.
Point p;
double x, y;
scanf("%d;%d", x, y);
p.setX(x);
p.setY(y);
Главное гармония ...
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: sokel Россия  
Дата: 05.03.11 11:17
Оценка:
Здравствуйте, Mazay, Вы писали:

S>>Со временем становится всё трудней определять "в каком же месте это значение устанавливаетя". Использование аксессоров дает такой бонус, как простота отслеживания доступа на запись.

M>Для этого есть data breakpoints.
Для того чтобы сработал data breakpoint надо ещё и ситуацию смоделировать, а это не всегда удается. Я говорю не про отладку а про анализ кода.

M>Функция initialize это плохо.

Чем плохо? Если инициализация действительно сложная, initialize лучше, чем ловля исключений в конструкторе.

M>Угу. А методы класса об этом и не знают. Потому что для обеспечения константности используют модификатор константности, а не область видимости private.

А никто и не говорит о константности. Например, какая нибудь структура проходных данных — пара методов для сериализации + набор аксессоров для чтения.
В любом случае точно известно, что переменную меняют только методы класса, а это уже сильно сужает область поиска.

M>Так называй поля не member_ а member.

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

S>> Метод, использующий большое количество сеттеров намекает на возможность рефакторинга в виде переноса кода в метод класса.

M>Угу. А потом искать место изменения переменной установкой брекпоинта в сеттере

M>
M>Point p;
M>

Да, для таких структурок вполне допустим прямой доступ. Но будь структура посложней, я бы предпочел какой нибудь point::parse().
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: jyuyjiyuijyu  
Дата: 05.03.11 13:31
Оценка:
как это все напоминает цитату "костыли для рожденных ползать" из статьи "C++ vs. C#"
http://vydrov.com/index.php/archives/128
с чего бы это ткие ассоцтиации ? лично у меня с того что вижу как люди придумывают фееричный бред про безопасность совершенно излишнюю в большинстве случаев ИМХО
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: Mazay Россия  
Дата: 05.03.11 15:27
Оценка:
Здравствуйте, sokel, Вы писали:

S>>>Со временем становится всё трудней определять "в каком же месте это значение устанавливаетя". Использование аксессоров дает такой бонус, как простота отслеживания доступа на запись.

M>>Для этого есть data breakpoints.
S>Для того чтобы сработал data breakpoint надо ещё и ситуацию смоделировать, а это не всегда удается. Я говорю не про отладку а про анализ кода.
Ставим модификатор константности на поле и компилятор показывает все точки потенциальной модификации. Это гораздо надёжнее, чем поиск сеттера по "уникальной" строке "setSize".

M>>Функция initialize это плохо.

S>Чем плохо? Если инициализация действительно сложная, initialize лучше, чем ловля исключений в конструкторе.
Тем что возможно существование неконсистентного объекта. Чем плоха ловля исключений в конструкторе?

M>>Угу. А методы класса об этом и не знают. Потому что для обеспечения константности используют модификатор константности, а не область видимости private.

S>А никто и не говорит о константности. Например, какая нибудь структура проходных данных — пара методов для сериализации + набор аксессоров для чтения.
S>В любом случае точно известно, что переменную меняют только методы класса, а это уже сильно сужает область поиска.
В ДАННОМ случае я бы всё-таки сделал константные поля и десериализующий конструктор. Но в принципе я понял что ты имеешь ввиду. Если контракт класса не подразумевает интерфейса для установки внутреннего состояния, то тогда всё правильно — делаем метод получения данных, но не даём возможности прямой модификации.

M>>Так называй поля не member_ а member.

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

S>>> Метод, использующий большое количество сеттеров намекает на возможность рефакторинга в виде переноса кода в метод класса.

M>>Угу. А потом искать место изменения переменной установкой брекпоинта в сеттере

M>>
M>>Point p;
M>>

S>Да, для таких структурок вполне допустим прямой доступ. Но будь структура посложней, я бы предпочел какой нибудь point::parse().

Это частый паттерн — передача ссылки для записи результата. Ну будет там не Point, а какой-нибудь BusinessEntityN337, что изменится?
Главное гармония ...
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: SleepyDrago Украина  
Дата: 05.03.11 15:30
Оценка: :)
Здравствуйте, Ytz, Вы писали:

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


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

J>>Он же "overengineering".

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


Годы идут а вопросы у падаванов одни и те же Для краткости процитирую ставшее классикой:

"Как называется метод для изменения переменной?" -"Метод для изменения переменной называется кретинизм."

(с) легко гуглится.
Управлять побочными эффектами надо обязательно. Только "get/set" к этому отношения не имеют — это структура проекта.
Re[12]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 06.03.11 05:47
Оценка:
Здравствуйте, MasterZiv, Вы писали:

MZ>On 04.03.2011 16:02, jazzer wrote:


>> LF>Если "v" скрыть, и определить интерфейс доступа к значениям, то ничего

>> лишнего никуда не попадет и не откуда не пропадет.
>> о чем я и говорю. Сеттеры-геттеры — не вариант.

MZ>Ещё кстати вспомнил, когда это нужно.

MZ>Если реализуются в какой-то системе property, типа как в QT,
MZ>и проперти эти требуют наличия указателей на функции (что более логично,
MZ>чем на данные).

Ну тут у нас все это заложено в систему сразу (так как иcпользуем QT), так что все нормально, интерфейс такой.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 06.03.11 08:15
Оценка:
Здравствуйте, SleepyDrago, Вы писали:

SD>Годы идут а вопросы у падаванов одни и те же Для краткости процитирую ставшее классикой:

SD>

SD> "Как называется метод для изменения переменной?" -"Метод для изменения переменной называется кретинизм."

(с) легко гуглится.


Для краткости процитирую ставшее классикой:

Кретинизм не делать методы, которые изменяют состояние объекта.

(с) легко гуглится.

SD>Управлять побочными эффектами надо обязательно. Только "get/set" к этому отношения не имеют — это структура проекта.


Вода-вода, приведи пример, уважаемый.
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 06.03.11 21:31
Оценка:
Здравствуйте, Аноним, Вы писали:

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

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

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


А>
А>    Class1 cl;
А>    cl.SetValue(1);
А>

А>вопрос, а зачем такой изврат?
Кто знает? Например у меня многие изменения в параметрах класса, а как правило set|get это доступ к desc класса, влечет за собой "ребилд" его представления.
тоесть посути выставление флага "инвалидейшн"
для этого нужны set.

Ну а также для проверок, ассертов, логов, дебага по брек поинтам

Итого get|set в классах в принцыпе не должно быть , так же как и public members

*Не путать структуры и классы.

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

А>и код будет более читабельным при использовании
Если бы мир был так прост.
я не волшебник, я только учусь!
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: fgrdn Земля  
Дата: 09.03.11 10:06
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:

предлагаю отобрать интернеты у школьников.
in c/c++ we trust!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: std.denis Россия  
Дата: 10.03.11 19:15
Оценка: +1
S>Приходится либо заходить в гетер, либо открывать файл с функцией и ставить там брейкпоинт, что бы не заходить в ненужные функции
В Cтудии есть "Step Into Specific" Хотя без шортката тоже не очень удобно
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: Ocelot  
Дата: 10.03.11 21:08
Оценка:
Помимо всего вышесказанного (хотя, имхо, и так более чем достаточно), свойство может быть:
— вычисляемым (нету соответствующего филда)
— наследуемым (хотя бы потенциально) — интересно, как вы для филда virtual сделаете?
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ocelot  
Дата: 10.03.11 21:42
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>

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

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

Нет, это то, что вы предлагаете, является "недо-engeneering".
Вы почему-то пердполагаете, что будете всегда владеть всем кодом.
А это полная чушь — сейчас система плагинов есть в практически в любой программе.
Свой-то код вы всегда можете перекомпилить. Но требовать того же от стороннего кода, который от вашего зависит...
Как вы думаете, долго протянет производитель бытовой техники, который вдруг решит, что его приборы должны работать от 170 вольт, а разъем для наушников сделает квадратным?
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: andrey_nado  
Дата: 10.03.11 22:34
Оценка:
Здравствуйте, IROV.., Вы писали:
IRO>Итого get|set в классах в принцыпе не должно быть , так же как и public members

Поясните, пожалуйста, Вашу мысль.
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: jazzer Россия Skype: enerjazzer
Дата: 11.03.11 00:13
Оценка: -1
Здравствуйте, Ocelot, Вы писали:

O>Вы почему-то пердполагаете, что будете всегда владеть всем кодом.

O>А это полная чушь — сейчас система плагинов есть в практически в любой программе.
O>Свой-то код вы всегда можете перекомпилить. Но требовать того же от стороннего кода, который от вашего зависит...
Ага, а еще "практически любая" программа работает с базой данных, сетью и DirectX. Это тоже стоит учесть, размышляя, делать ли в конкретном классе геттеры/сеттеры. Тоже одного уровня задачи.
Плагины — это особый случай.
Где есть плагины — там продумываются интерфейсы, но только там, где происходит взаимодействие. Потому что давать плагинам доступ вообще ко всему — это убить расширяемость на корню.
Зачем распространять приемы работы со сторонними плагинами на те части (а это может быть вся программа), где плагинов нет — я не понимаю.
Все равно что из-за того, что в программе есть пара классов, предназначенных для виртуального наследования, надо вообще все классы в программе осчастливить кучей виртуальных функций.

O>Как вы думаете, долго протянет производитель бытовой техники, который вдруг решит, что его приборы должны работать от 170 вольт, а разъем для наушников сделает квадратным?

Это к чему вообще было? Просто красивая фраза о пользе стандартизации вне связи с обсуждаемым предметом?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: DesertDragon Россия  
Дата: 11.03.11 03:38
Оценка: 2 (2) +2 -1
Здравствуйте, andrey_nado, Вы писали:

_>Здравствуйте, IROV.., Вы писали:

IRO>>Итого get|set в классах в принцыпе не должно быть , так же как и public members

_>Поясните, пожалуйста, Вашу мысль.


Претензии к Get|Set высказанные в этом топике являются результатом недоООП головного мозга.
Простая замена доступа к публичным переменным на гет/сет, не более чем синтаксический сахар, и по сути ничем не отличается от публичных переменных, так как не скрывает реализации класса. И соответственно не является инкапсуляцией.

Правильно названные методы класса, действительно скрывающие реализацию, в большинстве случаев не должны иметь слов Get/Set в своем имени.
Большинство учебных примеров по инкапсуляции в ООП к сожалению заканчиваются простыми геттерами/сеттерами, и справедливо вызывают вопросы "зачем это надо".
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: Sanik Россия http://sergeysthoughts.blogspot.com/
Дата: 11.03.11 03:40
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:


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


Из книжки Dewhurst-а

C++ Common Knowledge: Essential Intermediate Programming
"
Never, ever, simply provide a bunch of get/set operations on the data members of the implementation.
That’s not data abstraction; that’s laziness and lack of imagination.
"
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ocelot  
Дата: 11.03.11 15:45
Оценка:
J>Плагины — это особый случай.
Ага, вы начинаете сужать первоначальный случай

J>Где есть плагины — там продумываются интерфейсы, но только там, где происходит взаимодействие. Потому что давать плагинам доступ вообще ко всему — это убить расширяемость на корню.

J>Зачем распространять приемы работы со сторонними плагинами на те части (а это может быть вся программа), где плагинов нет — я не понимаю.
Не в плагинах дело. Дело в любом зависящем от вашего коде.
В любом мало-мальски нетривиальном проекте никто не может сказать заранее, где, кем и когда будет использоваться ваш класс. И если вам вдруг находу придет в голову все-таки изсенить филд на геттер, весь зависимый код придется корректировать. Вряд ли все будут этому рады.

J>Это к чему вообще было? Просто красивая фраза о пользе стандартизации вне связи с обсуждаемым предметом?

Не стандартизации, а следованию контракту. Меняя филд на геттер, вы меняете не только имплементацию, вы меняете контракт класса. Это потенциально (на практике — практически всегда) тянет за собой изменения в остальном коде. Если сразу использовать геттер, имплементацию можно менять, не затрагивая остальной код.
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ocelot  
Дата: 11.03.11 15:50
Оценка:
DD>Претензии к Get|Set высказанные в этом топике являются результатом недоООП головного мозга.
DD>Простая замена доступа к публичным переменным на гет/сет, не более чем синтаксический сахар, и по сути ничем не отличается от публичных переменных, так как не скрывает реализации класса. И соответственно не является инкапсуляцией.

Очень даже является.
Вы забываете, что геттер может получать значение путем "вычислений" или быть виртуальным.
С филдом такое не прокатит.
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: Vamp Россия  
Дата: 11.03.11 20:23
Оценка:
Ytz>Я понял — ради небольшого удобства открываем дыру в защите.
Я что-то не врубился, где здесь ЗАЩИТА? От чего ЗАЩИЩАЕМСЯ?
Да здравствует мыло душистое и веревка пушистая.
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: Vamp Россия  
Дата: 11.03.11 20:34
Оценка: +1
У меня ощущение, что это пришло из Багланд С++ Builder(или как там этот VCL-ный уродец назывался).
У них там были насильно введено понятие properties — чтобы можно было в гриде редактировать. И геттер-сеттер понадобился соответственно. Вот людям и показалось, что это красиво.
Кроме того, приятная поддержка со стороны IDE — нажимаешь кнопку "новое поле" — а она тебе сразу заводит и приватное поле, и публичный (ирландский) сеттер. 3 клика по клавишам — а размер программы увеличился на 10 строк! Начальство видит, как проект растет не по дням, а по часам.

Практической пользы в геттерах-сеттерах нет и никогда не было, только кривизна. Когда тебе надо, например, удалить пробелы из члена, и вместо того, чтобы писать

class.member.trim(),
ты пишешь:

string tmp = class.get_member();
tmp.trim();
class.set_member(tmp)

Это ненормально. Кстати, вот где раздолье для пост-коррекции — если однажды ты заменишь тип контейнера с одних строк на другие (чур, об auto ни словечка в этом контексте!).
Да здравствует мыло душистое и веревка пушистая.
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: enji  
Дата: 12.03.11 08:00
Оценка:
Здравствуйте, Vamp, Вы писали:

V>У меня ощущение, что это пришло из Багланд С++ Builder(или как там этот VCL-ный уродец назывался).

Свойства и в MSVC есть...
V>У них там были насильно введено понятие properties — чтобы можно было в гриде редактировать. И геттер-сеттер понадобился соответственно. Вот людям и показалось, что это красиво.
Не поясните, каким боком тут редактирование грида? Если вы про грид, привязанный к данным, то там есть датасет и датасурс, свойства тут не при чем. Если про обычный грид, то там надо отрабатывать события "редактирование"...

V>Практической пользы в геттерах-сеттерах нет и никогда не было, только кривизна. Когда тебе надо, например, удалить пробелы из члена, и вместо того, чтобы писать

V>class.member.trim(),
А часто ли надо так писать? Вы уверены, что class.member можно безболезненно триммить? Может тогда это будет struct.member?

По теме — лично я в классах использую геттеры и сеттеры. Часто поле можно извне только читать, а меняется оно через специальный метод (возможно вместе с другими полями).

Чтобы сэкономить на наборе кода, завел пару макросов —
PROPERTY_G(name, bool) -> bool name() const { return name_; }
PROPERTY_GS(name, bool) -> bool name() const { return name_; } void set_name(bool v) { name_ = v; }
Re[11]: доступ к мемберам класса(getter'ы и setter'ы)
От: enji  
Дата: 12.03.11 08:06
Оценка:
Здравствуйте, CreatorCray, Вы писали:

LF>>Не, лучше так:

LF>>
LF>>o.sort_v();
LF>>o.sort_w();
LF>>o.sort_x();
LF>>o.sort_y();
LF>>o.sort_z();
CC>...
LF>>


CC>Т.е. к каждой переменной надо ещё и sort и все остальные inplace алгоритмы приделывать, которые могут понадобится?


Мне почему-то кажется, что если класс содержит несколько разных контейнеров, то их крайне редко надо независимо изменять из клиентского кода. Обычно у такого класса есть несколько методов, которые вносят согласованные изменения во все контейнеры сразу и геттеры, которые возвращают константные ссылки на некоторые из таких контейнеров.

Ну а если это не так — то возможно нам просто нужен не класс, а обычная структура...
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 12.03.11 10:50
Оценка:
Здравствуйте, DesertDragon, Вы писали:

DD>Претензии к Get|Set высказанные в этом топике являются результатом недоООП головного мозга.

DD>Простая замена доступа к публичным переменным на гет/сет, не более чем синтаксический сахар, и по сути ничем не отличается от публичных переменных, так как не скрывает реализации класса. И соответственно не является инкапсуляцией.

Проблема в том что доступ к филдам не должен быть, это раз. Изучи принцып интерфейсов.
Во вторых, публичных переменных нету. Смотри пункт первый. Есть публичный интерфейс.

DD>Правильно названные методы класса, действительно скрывающие реализацию, в большинстве случаев не должны иметь слов Get/Set в своем имени.

Только потомучто у тебя алергия на слово Get|Set?

DD>Большинство учебных примеров по инкапсуляции в ООП к сожалению заканчиваются простыми геттерами/сеттерами, и справедливо вызывают вопросы "зачем это надо".

Это школьный пример, ты же на таблице умножений математику изучение не закончил? надеюсь
я не волшебник, я только учусь!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 12.03.11 11:00
Оценка:
Здравствуйте, andrey_nado, Вы писали:

_>Здравствуйте, IROV.., Вы писали:

IRO>>Итого get|set в классах в принцыпе не должно быть , так же как и public members
_>Поясните, пожалуйста, Вашу мысль.
Попробую

почему не должно быть public members я пояснять не буду, это зделали многие люди стоит только поискать.
А вот из не совсем очевидных (не надо get, set) поясню

что такое get|set в класике?
это так называемый setup object.

сетапить обьект нужно, только в начале его работы, дальнейшее сомнительно(разве что дебаг).
Если в начале, то почему это не сделать методами initialize|load?

другие методы должны быть связаны с его жизне-деятельностью, и они обычно в одну строчку как "Просто set|get" увы редко получаються, да и смысл у них другой.

Давай наверное так, ты покажешь пример, а я попробую обяснить как было бы по другому, ибо писарь из меня никакой

З.Ы. довольно интересная статья, не совсем по ООП, но хорошо касаеться ее, http://www.rsdn.ru/article/?1094
Автор(ы): Денисов Виктор Сергеевич
Дата: 20/02/2011
В статье рассматривается пример влияния тестов на архитектуру кода. Предложены формальные критерии тестируемости метода класса. Предложено определение исходящей зависимости. Указывается связь между полученными формальными определениями и смыслом эмпирических и эвристических правил полученных Робертом Мартином, Кентом Беком, Мартином Фаулером в работах посвященных качеству исходного кода.
я не волшебник, я только учусь!
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 12.03.11 16:07
Оценка: :)
Здравствуйте, Vamp, Вы писали:

Ytz>>Я понял — ради небольшого удобства открываем дыру в защите.

V>Я что-то не врубился, где здесь ЗАЩИТА? От чего ЗАЩИЩАЕМСЯ?

Молодец, что спросил

Вариант 1:

class Connection
{
public:
    void SetPort(unsigned port)
    {
        if (!PortAllowed(port))
            ...
        if (PortAlreadyInUse(port))
            ...
        Port_ = port;
    }

    bool Connect();

private:
    unsigned Port_;
};


Вариант 2:

struct Connection
{
    bool Connect();

    unsigned Port_;
};


Выбрав второй вариант тебе будет удобно писать connection.Port_ -= 20
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: andrey_nado  
Дата: 12.03.11 20:16
Оценка:
Здравствуйте, IROV.., Вы писали:

Я понял вашу мысль.

IRO>Давай наверное так, ты покажешь пример, а я попробую обяснить как было бы по другому, ибо писарь из меня никакой


Например, имеется некий объект с многочисленными настройками. Например, какая-нибудь числодробилка, которой можно выставить параметры типа величины временного шага, максимальной дельты и пр. Каждый параметр имеет значение по умолчанию и, в принципе, не обязательно должен устанавливаться клиентом. Но для спокойствия и поддержки нестандартных ситуаций возможность изменения параметров должна быть. Как её обеспечить, если не пользоваться геттерами/сеттерами? Параметры могут меняться скопом, но чаще поодиночке.
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: andrey_nado  
Дата: 12.03.11 20:39
Оценка:
Дискуссия, кажется, сместилась от неинтересного "публичные поля vs. геттеры/сеттеры" к более интересному "геттеры/сеттеры vs. бизнес-методы".

Выше высказано утверждение, что если класс открывает свои поля в чистом виде (даже посредством геттеров), это недоработка его интерфейса. Класс должно открывать функциональность, а поля — его сугубо личное дело.

Я согласен, но с оговоркой. Это правило не для всех классов, а только для тех, кто реализует бизнес-логику. То есть классы-"субъекты".

Но кроме них есть и классы "объекты", то есть то, с чем оперируют "субъекты". Простой пример: класс Account с данными банковского счёта. По сути это простая структура. Кроме сеттеров и геттеров он может иметь методы типа isValid() с проверкой целостности данных и пр. Но главная его задача: хранить и предоставлять данные.

По-моему, очевидная ошибка проектировки создавать некий класс SuperAccount, который не открывает поля, зато предоставлять кучу бизнес методов на все случаи жизни: от CRUD до печати. То есть, бизнес-логика реализуется многими классами. А поскольку оперируют они одной и той же логической сущностью, то эта сущность должна отразиться в простом классе Account с геттерами и сеттерами.
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 13.03.11 11:21
Оценка:
IRO>>Давай наверное так, ты покажешь пример, а я попробую обяснить как было бы по другому, ибо писарь из меня никакой

_>Например, имеется некий объект с многочисленными настройками. Например, какая-нибудь числодробилка, которой можно выставить параметры типа величины временного шага, максимальной дельты и пр. Каждый параметр имеет значение по умолчанию и, в принципе, не обязательно должен устанавливаться клиентом. Но для спокойствия и поддержки нестандартных ситуаций возможность изменения параметров должна быть. Как её обеспечить, если не пользоваться геттерами/сеттерами? Параметры могут меняться скопом, но чаще поодиночке.

Это не тот пример, ты тут сразу говоришь, "нужно" что бы был get|set, а именно "визуальная настройка эквалайзера"
я не волшебник, я только учусь!
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: DesertDragon Россия  
Дата: 13.03.11 15:39
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>Проблема в том что доступ к филдам не должен быть, это раз. Изучи принцып интерфейсов.

IRO>Во вторых, публичных переменных нету. Смотри пункт первый. Есть публичный интерфейс.

Опа. Тролли ин да хаус.
Если придраться больше не к чему, придеритесь к словам выдернутым из контекста.
Я писал о том, почему не должно быть простых геттеров/сеттеров для private members, также как не должно быть public members.

Ты умудрился в первом же предложении поменять смысл на противоположный и начать придираться к этому. До кучи начав нести околесицу про публичный интерфейс, следуя которой приватные данные переносятся из реализации в категорию интерфейса.
Отлично.
Иди тогда изучи русский язык, "принцЫп".

DD>>Правильно названные методы класса, действительно скрывающие реализацию, в большинстве случаев не должны иметь слов Get/Set в своем имени.

IRO>Только потомучто у тебя алергия на слово Get|Set?

Продолжай, я заинтригован

DD>>Большинство учебных примеров по инкапсуляции в ООП к сожалению заканчиваются простыми геттерами/сеттерами, и справедливо вызывают вопросы "зачем это надо".

IRO>Это школьный пример, ты же на таблице умножений математику изучение не закончил? надеюсь

Ты, судя повсему, закончил как-раз на ней.
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: DesertDragon Россия  
Дата: 13.03.11 16:03
Оценка: +1
Здравствуйте, andrey_nado, Вы писали:

_>Выше высказано утверждение, что если класс открывает свои поля в чистом виде (даже посредством геттеров), это недоработка его интерфейса. Класс должно открывать функциональность, а поля — его сугубо личное дело.

_>Я согласен, но с оговоркой. Это правило не для всех классов, а только для тех, кто реализует бизнес-логику. То есть классы-"субъекты".

Это правило для всех классов предоставляющий публичный интерфейс. Бизнес-логика тут не причем. Иначе это не ООП.

_>Но кроме них есть и классы "объекты", то есть то, с чем оперируют "субъекты". Простой пример: класс Account с данными банковского счёта. По сути это простая структура. Кроме сеттеров и геттеров он может иметь методы типа isValid() с проверкой целостности данных и пр. Но главная его задача: хранить и предоставлять данные.


Какие-то внутренние вспомогательные классы относящиеся к внутренней реализации модуля могут иметь методы get/set, если у них это явная основная функция. Поэтому я и писал про "большинство", а не "все".
Да и то, указанные данные по-хорошему должны хранится в реляционной базе данных, а не в классе Account. И класс c таким названием, в неакадемическом примере, для запроса данных скорее всего будет иметь методы с другими названиями, более адекватно отражающими работу с БД, а не Get/Set, каковые вводят в заблуждение, наводя на мысли о обсуждаемом анти-паттерне.
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 13.03.11 16:16
Оценка:
Здравствуйте, DesertDragon, Вы писали:

DD>Опа. Тролли ин да хаус.

DD>Если придраться больше не к чему, придеритесь к словам выдернутым из контекста.
DD>Я писал о том, почему не должно быть простых геттеров/сеттеров для private members, также как не должно быть public members.

DD>Ты умудрился в первом же предложении поменять смысл на противоположный и начать придираться к этому. До кучи начав нести околесицу про публичный интерфейс, следуя которой приватные данные переносятся из реализации в категорию интерфейса.

Каким раком приватные данные переносятся в категорию интерфейса?

Ну ну, тогда поясни по другому

Претензии к Get|Set высказанные в этом топике являются результатом недоООП головного мозга.
Простая замена доступа к публичным переменным на гет/сет, не более чем синтаксический сахар, и по сути ничем не отличается от публичных переменных, так как не скрывает реализации класса. И соответственно не является инкапсуляцией.


>>Простая замена доступа к публичным переменным на гет/сет, не более чем синтаксический сахар

Rly?? может расчет на чтото большее?

>>и по сути ничем не отличается от публичных переменных

Rly?? с публичными перемеными ты не сможешь создать технику "инвалидате" и многое многое другое.

>>так как не скрывает реализации класса. И соответственно не является инкапсуляцией.

Rly?? оно скрывает и являеться инкапсуляцией, хоть и тупой но инкапсуляцией

Или ты хотел сказать чтото совсем другое а мы "Тролли" тебя не понимаем?
я не волшебник, я только учусь!
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: DesertDragon Россия  
Дата: 13.03.11 16:57
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>Каким раком приватные данные переносятся в категорию интерфейса?


Хотел бы я знать. Ведь это твое утверждение: IRO>Во вторых, публичных переменных нету. Есть публичный интерфейс.

IRO>Rly?? с публичными перемеными ты не сможешь создать технику "инвалидате" и многое многое другое.


Если использую property, то смогу.

IRO>Rly?? оно скрывает и являеться инкапсуляцией, хоть и тупой но инкапсуляцией


Что же оно скрывает интересно? Предоставляет доступ к технике "инвалидате" — да. Скрывают — нет.

Речь не о том, что простые геттеры/сеттеры с именем внутренней переменной класса в имени метода бесполезны в принципе. А о том что они не имеют отношения к инкапсуляции. Если вы хотите скрыть реализацию класса Heater в виде приватной переменной класса temperature, то не надо создавать пару методов GetTemperature/SetTemperature. У подобного класса должны быть методы отражающие его функциональность, Warm/Cool например.
Метод GetTemperature может быть у класса Indicator, без парного метода Set естесствено. Вот это будет хорошее, годное ООП.

А обсуждаемые геттеры/сеттеры оставьте как один из вариантов реализации пропертей, используемых для валидации данных и прочих внутренне-отладочных нужнд, не имеющих отношение к объектно-ориентированному проектированию как таковому.

Да, я берусь утверждать, что большинство учебных материалов, включая статью по инкапсуляции в википедии, и даже знаменитый учебник Буча, вводит в заблуждение новичков, приводя get/set как хороший пример ООП. Это плохой пример, негодный
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: DesertDragon Россия  
Дата: 13.03.11 17:23
Оценка:
Здравствуйте, Ocelot, Вы писали:

O>Вы забываете, что геттер может получать значение путем "вычислений" или быть виртуальным.

O>С филдом такое не прокатит.

Еще раз для особо хитрых.
Я не говорил что филд всегда лучше геттера. Это говорил топикастер.
А я объяснял, почему геттер не сильно лучше филда в плане скрытия реализации. И почему он не имеет отношения к объекто-ориентированному проектированию.
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 13.03.11 17:28
Оценка:
Здравствуйте, DesertDragon, Вы писали:

DD>Здравствуйте, IROV.., Вы писали:


IRO>>Каким раком приватные данные переносятся в категорию интерфейса?

DD>Хотел бы я знать. Ведь это твое утверждение: IRO>Во вторых, публичных переменных нету. Есть публичный интерфейс.
И как из моей ффразы вытикает твое утверждение?

IRO>>Rly?? с публичными перемеными ты не сможешь создать технику "инвалидате" и многое многое другое.

DD>Если использую property, то смогу.
А что такое property?

IRO>>Rly?? оно скрывает и являеться инкапсуляцией, хоть и тупой но инкапсуляцией

DD>Что же оно скрывает интересно? Предоставляет доступ к технике "инвалидате" — да. Скрывают — нет.
??? Ты бредишь? что такое сокрытие? разве я не скрыл от тебя технику "инвалидате"?

DD>Речь не о том, что простые геттеры/сеттеры с именем внутренней переменной класса в имени метода бесполезны в принципе. А о том что они не имеют отношения к инкапсуляции. Если вы хотите скрыть реализацию класса Heater в виде приватной переменной класса temperature, то не надо создавать пару методов GetTemperature/SetTemperature. У подобного класса должны быть методы отражающие его функциональность, Warm/Cool например.

DD>Метод GetTemperature может быть у класса Indicator, без парного метода Set естесствено. Вот это будет хорошее, годное ООП.
Почитай мой топик ниже, я там сказал именно тоже самое и фраза "нету публичных переменных, есть публичный интерфей"

DD>А обсуждаемые геттеры/сеттеры оставьте как один из вариантов реализации пропертей, используемых для валидации данных и прочих внутренне-отладочных нужнд, не имеющих отношение к объектно-ориентированному проектированию как таковому.

Имеет, но не такое эпическое как ты думаешь. Это лиж техника.

DD>Да, я берусь утверждать, что большинство учебных материалов, включая статью по инкапсуляции в википедии, и даже знаменитый учебник Буча, вводит в заблуждение новичков, приводя get/set как хороший пример ООП. Это плохой пример, негодный

Негодный, это я тебе тоже написал выше
я не волшебник, я только учусь!
Re[9]: доступ к мемберам класса(getter'ы и setter'ы)
От: DesertDragon Россия  
Дата: 13.03.11 17:50
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>И как из моей ффразы вытикает твое утверждение?


А так, что публичные переменные класса, это не публичный интерфейс, а ошибочно открытые приватные данные. Если действительно нужны открытые данные, то используйте простые структуры. Члены-переменые которых, также не являются публичным интерфейсом.
Своей же фразой ты утверждаешь обратное.

IRO>А что такое property?


Очень смешно, но толсто.

IRO>??? Ты бредишь? что такое сокрытие? разве я не скрыл от тебя технику "инвалидате"?


Отнюдь нет. В данном случае нельзя сказать, что ты "скрыл технику инвалидате", ты наоборот предоставил доступ к использованию этой техники. Также ты открыл имя внутренней приватной переменной и доступ к ней. Да, это полезный, удобный, контролируемый доступ.
Но это НЕ скрытие _реализации класса_.

Вот для того что бы не возникало подобных споров я и хочу уточнить термин инкапсуляции. Из-за расплывчатого толкования которого и возникет усложнение архитектуры при применении ООП, вместо упрощения.
Re[9]: доступ к мемберам класса(getter'ы и setter'ы)
От: Desert Dragon Россия  
Дата: 13.03.11 18:17
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>Негодный, это я тебе тоже написал выше


В таком случае предлагаю помирится коллега и почти полный тезка
Re[10]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 13.03.11 21:16
Оценка:
Здравствуйте, DesertDragon, Вы писали:

DD>Здравствуйте, IROV.., Вы писали:


IRO>>И как из моей ффразы вытикает твое утверждение?

DD>А так, что публичные переменные класса, это не публичный интерфейс, а ошибочно открытые приватные данные. Если действительно нужны открытые данные, то используйте простые структуры. Члены-переменые которых, также не являются публичным интерфейсом.
DD>Своей же фразой ты утверждаешь обратное.
Я говорю что переменым не место в интерфейсе, вот и все.
Как ты вичитал чтото другое? )


IRO>>А что такое property?

DD>Очень смешно, но толсто.
В С++ нету property

ололо

IRO>>??? Ты бредишь? что такое сокрытие? разве я не скрыл от тебя технику "инвалидате"?


DD>Отнюдь нет. В данном случае нельзя сказать, что ты "скрыл технику инвалидате", ты наоборот предоставил доступ к использованию этой техники. Также ты открыл имя внутренней приватной переменной и доступ к ней. Да, это полезный, удобный, контролируемый доступ.

DD>Но это НЕ скрытие _реализации класса_.
Ты прорицатель, смотриш на метод и знаешь как он работает?
Открыть имя приватной переменной это плохо? доступ? отнють, там может стоять проверка которая не пустит тебя к ней
Это скритие, поверь )


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

Я тебя обрадую наш спор, не о инкапсуляции как высшей материи, а просто о техническом приеме "почему get|set круче pure members" а про ООП я уже выше писал что повальный get|set на все мемберы там не должно быть, но бывают, и если бывают то только через get|set
я не волшебник, я только учусь!
Re[10]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 13.03.11 21:17
Оценка:
Здравствуйте, Desert Dragon, Вы писали:

DD>Здравствуйте, IROV.., Вы писали:


IRO>>Негодный, это я тебе тоже написал выше


DD>В таком случае предлагаю помирится коллега и почти полный тезка

А я и не ругался :Р, в споре рождаеться истина.
Я вытягиваю знания у тебя, ты у меня, это норма

Просто некоторые зляться, а некоторые так
я не волшебник, я только учусь!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: AndrewJD США  
Дата: 14.03.11 08:29
Оценка:
Здравствуйте, DesertDragon, Вы писали:

DD>Да и то, указанные данные по-хорошему должны хранится в реляционной базе данных, а не в классе Account. И класс c таким названием, в неакадемическом примере, для запроса данных скорее всего будет иметь методы с другими названиями, более адекватно отражающими работу с БД, а не Get/Set, каковые вводят в заблуждение, наводя на мысли о обсуждаемом анти-паттерне.


ИМХОб всегда считалось хорошим тоном разделять биснес логику и работу с базой(хранилищем). Поэтому странно иметь в бизнес логике код с методами "адекватно отражающими работу с БД (с)".
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: Vamp Россия  
Дата: 14.03.11 12:45
Оценка:
Ytz>Молодец, что спросил
Антипример.

Ytz> if (!PortAllowed(port))

Твой код хорошо знает подробности имплементации TCP стека на конкретной архитектуре/системе? И ты от Android на ARM до Solaris 10 на Sub знаешь диапазон разрешенных портов и можешь корректно имплементировать PortAllowed? "Не верю!" Так что опять защита на уровне страуса.

Ytz> if (PortAlreadyInUse(port))

А это вообще неверно. Может, сейчас порт in use, а ко времени коннекта станет свободен?

Ytz>Выбрав второй вариант тебе будет удобно писать connection.Port_ -= 20

А может, это будет допустимо на целевой архитектуре? В общем, пока не убедил.
Да здравствует мыло душистое и веревка пушистая.
Re[9]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 14.03.11 13:31
Оценка:
Здравствуйте, Vamp, Вы писали:

Ytz>> if (!PortAllowed(port))

V>Твой код хорошо знает подробности имплементации TCP стека на конкретной архитектуре/системе? И ты от Android на ARM до Solaris 10 на Sub знаешь диапазон разрешенных портов и можешь корректно имплементировать PortAllowed? "Не верю!" Так что опять защита на уровне страуса.

Нет, просто при старте был создан пул портов и теперь можно проверить из пула порт или нет.

Ytz>> if (PortAlreadyInUse(port))

V>А это вообще неверно. Может, сейчас порт in use, а ко времени коннекта станет свободен?

В контексте моей задачи верно — берется порт из пула, потом возвращается обратно.

Ytz>>Выбрав второй вариант тебе будет удобно писать connection.Port_ -= 20

V>А может, это будет допустимо на целевой архитектуре? В общем, пока не убедил.

Я и не старался В любом случае это просто иллюстрация.
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 14.03.11 15:45
Оценка: :)
Здравствуйте, jazzer, Вы писали:

J>А еще бывают:

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

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

J>успехов с геттерами-сеттерами.
Ты привел пример из другой оперы, подменил понятия, молодец возми пирожек, развел кучу троллей на ровном месте.
что такое cache.Size *= 1000?

это уже какоето действие/метод — значит и будет такой метод mulSize(1000),
и то мне кажеться это по детскому сценарию, прочитал 3 абзаца ООП и сразу моск помер(overengineering — думать это тупо).
потомучто mulSize это не ООП это просто техника скрытия реализации.

У этой сущьности есть какието логические методы работы с ним. Вот их и нужно декларировать, грубо говоря начинать разработку системы с

Интерфейсов Теста и Мока.

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

Потомучто развивиать это невозможно.

я не волшебник, я только учусь!
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: Vamp Россия  
Дата: 14.03.11 15:48
Оценка:
IRO>потомучто mulSize это не ООП это просто техника скрытия реализации.
Ну здравствуй племя молодое, незнакомое .

IRO>У этой сущьности есть какието логические методы работы с ним. Вот их и нужно декларировать, грубо говоря начинать разработку системы с

IRO>Интерфейсов Теста и Мока.
Какие знакомые песни...

IRO>И когда ты потратишь немного времени(имея за собой годы опыта, и не повтореного, как обычно это бывает)

IRO>то поймешь что такие конструкции — зло.
Вот тебя я лично не знаю, а Джаззера — знаю. И точно тебе говорю, говорить ему о недостатке опыта — это тыкать пальцем в небо.
Да здравствует мыло душистое и веревка пушистая.
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: Ytz https://github.com/mtrempoltsev
Дата: 14.03.11 17:29
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Вот тебя я лично не знаю, а Джаззера — знаю. И точно тебе говорю, говорить ему о недостатке опыта — это тыкать пальцем в небо.


При всем уважении и к твоему опыту и к опыту Джаззера (ни капли в нем не сомневаюсь), не могу согласиться с формулировкой сеттеры и геттеры — ООП-головного мозга и оверинжениринг. Все должно быть к месту. Понятно, что в простом случае:

struct Point
{
    int X;
    int Y;
};


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

void SetX(unsigned x)
{
    assert(x < SceneWidth());
    ...
}


Поправьте меня пожалуйста, если я не прав.

Кстати, Джаззер, лихо начав, потом вполне корректно пояснил свою мысль
Автор: jazzer
Дата: 04.03.11
, не оставив предмета для возражений.
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 14.03.11 22:15
Оценка:
Здравствуйте, Vamp, Вы писали:

IRO>>У этой сущьности есть какието логические методы работы с ним. Вот их и нужно декларировать, грубо говоря начинать разработку системы с

IRO>>Интерфейсов Теста и Мока.
V>Какие знакомые песни...
точно знакомые? или слышал звон

IRO>>И когда ты потратишь немного времени(имея за собой годы опыта, и не повтореного, как обычно это бывает)

IRO>>то поймешь что такие конструкции — зло.
V>Вот тебя я лично не знаю, а Джаззера — знаю. И точно тебе говорю, говорить ему о недостатке опыта — это тыкать пальцем в небо.
Примени свои слова к себе

V>Ну здравствуй племя молодое, незнакомое .

Не знаю но осуждаю ))

Кстати там выше уже ответили, да и почитал про "исправление" своей мысли твоего джаззера
я не волшебник, я только учусь!
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 14.03.11 22:16
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>потомучто mulSize это не ООП это просто техника скрытия реализации.

Сегодня чисто случайно узнал что это называеться — "Лазанья", уже забыл кто сказал
я не волшебник, я только учусь!
Re[8]: доступ к мемберам класса(getter'ы и setter'ы)
От: Desert Dragon Россия  
Дата: 15.03.11 02:02
Оценка:
Здравствуйте, Ytz, Вы писали:

Ytz> не могу согласиться с формулировкой сеттеры и геттеры — ООП-головного мозга и оверинжениринг. Все должно быть к месту.


Вот, давайте таки отделим уже мух от котлет: сеттеры и геттеры могут быть оверинженирингом, но не могут быть ООП-ом головногом мозга.

Геттеры и сеттеры, также как и просто открытые данные класса, методологически, не являются интерфейсом класса. Они не должны быть часть контракта.
Потому что проблемы, которые пытаются решать создавая публичные методы Get/Set, вызванны именно тем, что открытые данные, по сути, были частью контракта. Поменяйте архитектуру так что убрать их из контракта, и скорее всего у вас не будет того количества точек доступа к этим переменным что бы понадобилось вводить геттеры/сеттеры. То есть в данном случае они могут быть оверинженирингом.

Технически, всё публичное в классе это интерфейс. Поэтому методы Get/SetИмяПеременной предназначенные для определения единной точки доступа к переменной должны быть только приватными. И, как приватные методы, являются частью реализации. Соответственно, как реализация класса, не имеют отношения к построению иерархий классов и к объекто-ориентированному проектированию в целом.
То есть сеттеры и геттеры не могут быть ООП-ом головного мозга в принципе, поскольку это не ООП.
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 16.03.11 15:26
Оценка: 13 (2)
С точки зрения design by contract:

1) Каждый элемент интерфейса класса (будь то открытая функция-член, друг, или открытое поле) накладывает некоторые ограничения на свое использование -- preconditions.
Например, не передавать отрицательных чисел в качестве аргумента, не передавать указатели на удаленную память, передавать в качестве параметра шаблона CopyConstructable и т.п.
2) При использовании интерфейса с требуемыми preconditions, объект всегда должен оставаться в согласованном валидном состоянии -- invariants.
3) При изменении preconditions задача разработчика интерфейса -- пересмотреть всех клиентов и оповестить их о том, что контракт изменился.
4) В изначальном примере с сеттерами/геттерами, preconditions сеттера гласят: "передавай любое значение". Т.е. совпадают с "preconditions" которые имеет открытое поле класса.

Из (4) следует, что никакой разницы с точки зрения корректности геттеры/сеттеры не добавляют.
Из (3) следует, что если вдруг диапазон допустимых значений придется ограничить, нам все равно придется перелопатить клиентский код -- убедиться в том, что он не нарушает новых preconditions, или поменять его, чтоб не нарушал. Сделать это несложно, как здесь уже говорили выше -- делаем поле класса закрытым, и компилятор находит нам все места, которые надо поправить.

Я считаю, что лучший future-proof вообще -- реализовать минимально-простое решение, удовлетворяющее сегодняшним требованиям, ну может еще завтрашним, если мы уже знаем, куда идем.
Как говорится, магистр Йода учит нас думать о будущем, но не в ущерб настоящему.
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 19.03.11 10:23
Оценка:
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Из (4) следует, что никакой разницы с точки зрения корректности геттеры/сеттеры не добавляют.

А ты сам придумал прекондишн сетера и гетера? страно, и предумал же в свою пользу, молодец — толсто троллишь!

AP>Из (3) следует, что если вдруг диапазон допустимых значений придется ограничить, нам все равно придется перелопатить клиентский код -- убедиться в том, что он не нарушает новых preconditions, или поменять его, чтоб не нарушал. Сделать это несложно, как здесь уже говорили выше -- делаем поле класса закрытым, и компилятор находит нам все места, которые надо поправить.


Ухты, а я нажму в VA кнопочку и мне покажет все места использования за 5 секунд, а ты будешь час перекомпиливать и то не 1 раз. Да и ты представляешь что будет если ты пишешь миделваре, или кода тонны, и твоим модулем пользуються 10-20 программистов? Думаю врядли ты это представляешь.

— круты пацаны напишут асерт/варнинг/ексепшн + добавят к мануалу инфу, и получат профит, в виде делегирования своей работы на 10-20 человек.

AP>Я считаю, что лучший future-proof вообще -- реализовать минимально-простое решение, удовлетворяющее сегодняшним требованиям, ну может еще завтрашним, если мы уже знаем, куда идем.

это значит, что ты часто пишешь код не зная что получиться в результате
Тогда да оправдывает, скорость переписывания кода, без get|set гораздо быстрее

AP>Как говорится, магистр Йода учит нас думать о будущем, но не в ущерб настоящему.

Заставь дурака богу молиться он и лоб себе расшибет!
я не волшебник, я только учусь!
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 19.03.11 10:45
Оценка:

Когда я был студентом, я сдавал право одной очень милой женщине. Она была практикующим юристом, и я ожидал, что такой специалист меня сейчас будет гонять от и до по всему конспекту.
Она посмотрела на меня и, ничего не спрашивая, поинтересовалась:
— Оценку вам какую ставить?
— Э... Пять хотелось бы
— Отлично, — сказала она, и стала писать в зачётке
— А вы что, даже ничего спрашивать не будете? — удивился я.
Она оторвалась от заполнения зачётки, внимательно посмотрела на меня и сказала:
— Запомните, молодой человек, чем меньше вы знаете, тем более ценна я как специалист.
Эта фраза мне запомнилась на всю жизнь и больше я не страдал фигнёй во время занятий.
И сейчас самое время мне, уже доценту и одновременно практикующему проектировщику зданий, повторить то же самое:
Господа студенты, не учитесь, пожалуйста! Старайтесь как можно больше получить на халяву! Чем меньше вы знаете по окончании института, тем более ценен я как специалист и тем большую зарплату я могу потребовать за свои услуги!

я не волшебник, я только учусь!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: Alexander Poluektov Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 19.03.11 11:04
Оценка:
Здравствуйте, IROV.., Вы много писали.
При сохранении выбранного Вами тона, это будет последний ответ Вам.

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

Напомню изначальный пример:
class Class1
{
  int  value;

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


AP>>Из (4) следует, что никакой разницы с точки зрения корректности геттеры/сеттеры не добавляют.

IRO>А ты сам придумал прекондишн сетера и гетера?

Нет, они следуют из приведенного фрагмента кода -- документированной спецификации нет, реализация доступна в месте объявления, следовательно либо реализация сама является спецификацией, либо код писал программист, не понимающий базовых механизмов, обеспечивающих корректность кода и его клиентов. Я предположил первое.

AP>>Из (3) следует, что если вдруг диапазон допустимых значений придется ограничить, нам все равно придется перелопатить клиентский код -- убедиться в том, что он не нарушает новых preconditions, или поменять его, чтоб не нарушал. Сделать это несложно, как здесь уже говорили выше -- делаем поле класса закрытым, и компилятор находит нам все места, которые надо поправить.


IRO>Ухты, а я нажму в VA кнопочку и мне покажет все места использования за 5 секунд, а ты будешь час перекомпиливать и то не 1 раз.


Не думаю, что у Вас есть технические аргументы в пользу приведенных цифр ("5 секунд" против "час и то не 1 раз"), а эмоциональные здесь не работают, игнорируем.

IRO>Да и ты представляешь что будет если ты пишешь миделваре, или кода тонны, и твоим модулем пользуються 10-20 программистов?


Да, представляю. Бываю по обе стороны баррикад.
В случае опубликованного middleware изменения контрактов должны решаться на уровне версионности. Почитайте, например, это: http://semver.org/
В случае внутреннего модуля, изменение клиентов для соответствия новой спецификации (или хотя бы явное оповещение об этом) считаю необходимой практикой: если я делаю изменение в открытом интерфейсе, и ломаю этим существующий код, то я и должен чинить поломанный код.
Если у меня есть SetValue, которая сегодня принимает любые целые значения, а завтра только четные числа, и у нее это 10-20 клиентов, то это моя проблема, когда завтра 10-20 программистов начнут приходить ко мне и спрашивать, что за ассерты/предупреждения/исключения они получают в существующем коде.

IRO>- круты пацаны напишут асерт/варнинг/ексепшн + добавят к мануалу инфу, и получат профит, в виде делегирования своей работы на 10-20 человек.


Привет крутым пацанам.
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 19.03.11 11:39
Оценка: -1
Здравствуйте, Alexander Poluektov, Вы писали:

AP>Здравствуйте, IROV.., Вы много писали.

AP>При сохранении выбранного Вами тона, это будет последний ответ Вам.

AP>Постараюсь вытянуть из Вашего потока хамства технические вопросы.


AP>Напомню изначальный пример:

AP>
AP>class Class1
AP>{
AP>  int  value;

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

Тебе дать определение троллинга??? или цепляние к словам? может это все такие простейший пример элюстрирующию проблематику?
а не реальный код, понятием которым ты и подменил сущьность.

AP>Нет, они следуют из приведенного фрагмента кода -- документированной спецификации нет, реализация доступна в месте объявления, следовательно либо реализация сама является спецификацией, либо код писал программист, не понимающий базовых механизмов, обеспечивающих корректность кода и его клиентов. Я предположил первое.

Ты всегда принимаешь все за чистую монету? Может это не код, а пример?
Что по твоему делает этот класс — с эпическим названием Class1? инкапсулирует value? возможно.
Но чаще это класический троллинг.

IRO>>Ухты, а я нажму в VA кнопочку и мне покажет все места использования за 5 секунд, а ты будешь час перекомпиливать и то не 1 раз.

AP>Не думаю, что у Вас есть технические аргументы в пользу приведенных цифр ("5 секунд" против "час и то не 1 раз"), а эмоциональные здесь не работают, игнорируем.
Ололо, вперед качать VA, и просить руководство купить лицензию! ну или сделать как всегда

IRO>>Да и ты представляешь что будет если ты пишешь миделваре, или кода тонны, и твоим модулем пользуються 10-20 программистов?


AP>Да, представляю. Бываю по обе стороны баррикад.

AP>В случае опубликованного middleware изменения контрактов должны решаться на уровне версионности. Почитайте, например, это: http://semver.org/
Это както относиться к вопросу? ты говоришь как оповестить _читающего_ юзера, а я говорю как оповестить _глупого_ юзера, глупый >>>> читающих

AP>В случае внутреннего модуля, изменение клиентов для соответствия новой спецификации (или хотя бы явное оповещение об этом) считаю необходимой практикой: если я делаю изменение в открытом интерфейсе, и ломаю этим существующий код, то я и должен чинить поломанный код.


Ололо, ты настолько грамотный что являешся специалистом во всех областях программирования, и конечно же знаешь как правильно собираються, и как они работают все модули проекта? — огорчу, чаще всего в таких грамотных системах на этапе Девелопинга, используют практику Интерфейсы плюс DLL(грубо говоря тебе даже не всегда дадут реализацию этого модуля), обяснять почему?

AP>Если у меня есть SetValue, которая сегодня принимает любые целые значения, а завтра только четные числа, и у нее это 10-20 клиентов, то это моя проблема, когда завтра 10-20 программистов начнут приходить ко мне и спрашивать, что за ассерты/предупреждения/исключения они получают в существующем коде.

Правильно прийдут, ты же ведь не напишешь в этом ассерте/предупреждении/исключении — краткую анотацию что не так, и ссылку на описание интерфейся в мануале, а зря.
И даже если и прийдут, это гораздо проще обьяснить новую политику партии чем сидеть и писать за них, как ты предложил выше.
И опять же в компаниях принято пользоваться(если это возможно) политикой depricated и рядом писать новый интерфейс — даже пусть он будет называться SetValue2.
А если это внутрение вопросы, то на очередном заседании решаються изменения к интерфейсу и все к этому готовы

IRO>>- круты пацаны напишут асерт/варнинг/ексепшн + добавят к мануалу инфу, и получат профит, в виде делегирования своей работы на 10-20 человек.

AP>Привет крутым пацанам.
Передам, жаль редко встречаються в жизни )))
я не волшебник, я только учусь!
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: disasm  
Дата: 19.03.11 12:38
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>Здравствуйте, Alexander Poluektov, Вы писали:


AP>>Здравствуйте, IROV.., Вы много писали.

AP>>При сохранении выбранного Вами тона, это будет последний ответ Вам.

AP>>Постараюсь вытянуть из Вашего потока хамства технические вопросы.


AP>>Напомню изначальный пример:

AP>>
AP>>class Class1
AP>>{
AP>>  int  value;

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

IRO>Тебе дать определение троллинга??? или цепляние к словам? может это все такие простейший пример элюстрирующию проблематику?
IRO>а не реальный код, понятием которым ты и подменил сущьность.

чувствуется рука уверенного в себе человека
тогда далеко ходит не будем уважаемый yuriy_levchenko
и что бы остудить ваш пыл
вы всем постараетесь обьяснить вот этот код
http://axe-engine.svn.sourceforge.net/viewvc/axe-engine/src/Lib/PropertySystem/String.cpp?revision=86&amp;view=markup
namespace AxeProperty
 
5 {
6         //////////////////////////////////////////////////////////////////////////
7         PROPERTY_VISITOR_IMPLEMENT(String);
8         //////////////////////////////////////////////////////////////////////////
9         String::String( const TypePtr & _type )
10                 : Base(_type)
11         {
12         }
13         //////////////////////////////////////////////////////////////////////////
14         void String::setValue( const std::string & _value )
15         {
16                 m_value = _value;
17         }
18         //////////////////////////////////////////////////////////////////////////
19         const std::string & String::getValue() const
20         {
21                 return m_value;
22         }
23 }


ну так же что бы поднять на должный уровень вашу компетенцию в вопросах кодинга

обилие public:
http://axe-engine.svn.sourceforge.net/viewvc/axe-engine/src/Lib/PropertySystem/Array.hpp?revision=86&amp;view=markup

конструкций if( isTrue() == false)
http://menge-engine.svn.sourceforge.net/viewvc/menge-engine/branches/ConstString3/src/Menge/HotSpotImage.cpp?r1=3142&amp;r2=3141&amp;pathrev=3142

ну итд, ваших примеров на sf.net хватает
так что, увыжаемый IROV aka yuriy_levchenko задумайтесь о том что вам люди сказали выше
> AP>>Постараюсь вытянуть из Вашего потока хамства технические вопросы.
Re[2]: доступ к мемберам класса(getter'ы и setter'ы)
От: robin_of_the_wood Россия  
Дата: 19.03.11 12:59
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>

IRO>И сейчас самое время мне, уже доценту и одновременно практикующему проектировщику зданий, повторить то же самое:

Казалось бы при чем тут геттеры и сеттеры.
Но видимо с высоты практически спроектированных зданий(заметьте не кем попало спроектированных, а целым доцентом) оно виднее.
Шутка конечно, но с точки зрения программирования, для подтверждения высокого класса больше подходит обнародование размера детородного органа. Сразу понятно. А то — доцент.
Проектирование велосипедов для слепых жирафов
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 19.03.11 13:41
Оценка:
Здравствуйте, disasm, Вы писали:

IRO>>Тебе дать определение троллинга??? или цепляние к словам? может это все такие простейший пример элюстрирующию проблематику?

IRO>>а не реальный код, понятием которым ты и подменил сущьность.

D>чувствуется рука уверенного в себе человека

D>тогда далеко ходит не будем уважаемый yuriy_levchenko
D>и что бы остудить ваш пыл
D>вы всем постараетесь обьяснить вот этот код
D>http://axe-engine.svn.sourceforge.net/viewvc/axe-engine/src/Lib/PropertySystem/String.cpp?revision=86&amp;view=markup
Код нужен для симуляции ORM между сервером и клиентом, также есть мапинг этого в различные скрипты (Python, Lua)

D>
D>namespace AxeProperty
 
D>5 {
D>6         //////////////////////////////////////////////////////////////////////////
D>7         PROPERTY_VISITOR_IMPLEMENT(String);
D>8         //////////////////////////////////////////////////////////////////////////
D>9         String::String( const TypePtr & _type )
D>10                 : Base(_type)
D>11         {
D>12         }
D>13         //////////////////////////////////////////////////////////////////////////
D>14         void String::setValue( const std::string & _value )
D>15         {
D>16                 m_value = _value;
D>17         }
D>18         //////////////////////////////////////////////////////////////////////////
D>19         const std::string & String::getValue() const
D>20         {
D>21                 return m_value;
D>22         }
D>23 }
D>


D>ну так же что бы поднять на должный уровень вашу компетенцию в вопросах кодинга

Спасибо подняли, на фоне вашей некомпетентности.

D>обилие public:

D>http://axe-engine.svn.sourceforge.net/viewvc/axe-engine/src/Lib/PropertySystem/Array.hpp?revision=86&amp;view=markup
И что бы ты тут воткнул бы в протект/приват? )

D>конструкций if( isTrue() == false)

D>http://menge-engine.svn.sourceforge.net/viewvc/menge-engine/branches/ConstString3/src/Menge/HotSpotImage.cpp?r1=3142&amp;r2=3141&amp;pathrev=3142

if( ResourceManager::get()->hasResource( resourceHotspotImageName ) == false )

Ты об этом? По подробней, что тебя смущает.

D>ну итд, ваших примеров на sf.net хватает

Хватает.

D>так что, увыжаемый IROV aka yuriy_levchenko задумайтесь о том что вам люди сказали выше

Извини, поищи еще.
я не волшебник, я только учусь!
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 19.03.11 13:43
Оценка: -1
Здравствуйте, robin_of_the_wood, Вы писали:

___>Казалось бы при чем тут геттеры и сеттеры.

___>Но видимо с высоты практически спроектированных зданий(заметьте не кем попало спроектированных, а целым доцентом) оно виднее.
___>Шутка конечно, но с точки зрения программирования, для подтверждения высокого класса больше подходит обнародование размера детородного органа. Сразу понятно. А то — доцент.
Толсто
я не волшебник, я только учусь!
Re: доступ к мемберам класса(getter'ы и setter'ы)
От: wvoquine  
Дата: 19.03.11 14:12
Оценка:
Спасибо всем за интересное эмоциональное обсуждение.

Мне лично больше всего понравилась позиция Desert Dragon. Геттеры и сеттеры писать неприятно, а потому и нужно придерживаться данного стиля (геттеры/сеттеры для открытых полей класса (не структуры)), чтобы каждый раз, когда приходится их писать, задумываться о том, как можно было бы организовать интерфейс класса более изящно.

Геттеры/сеттеры могут оказаться полезными, когда мы захотим адаптировать под наши нужды другой класс, у которого мемберы называются по-другому, хотя по сути интерфейса он не очень отличается от нашего.

Кстати, по поводу читабельности. Как известно, любая функция (без throw()) потенциально может быть источником исключений. Потому, если поле имеет встроенный тип, то прямое обращение к нему может несколько выиграть в читабельности за счёт этого. Но, правда, мы должны при точно знать, что имеем дело со встроенными типами
To be is to be the value of a variable
Re[3]: доступ к мемберам класса(getter'ы и setter'ы)
От: andrey_nado  
Дата: 20.03.11 21:21
Оценка:
Здравствуйте, DesertDragon, Вы писали:
DD>Какие-то внутренние вспомогательные классы относящиеся к внутренней реализации модуля могут иметь методы get/set, если у них это явная основная функция. Поэтому я и писал про "большинство", а не "все".

Если какой-нибудь интерфейсный метод принимает 20 штук параметров, их естественно поместить в структуру. А отсюда уже недалеко и до простого класса с геттерами и сеттерами. И почему класс Account не может быть параметром или результатом интерфейсных методов?

DD>Да и то, указанные данные по-хорошему должны хранится в реляционной базе данных, а не в классе Account.


Храниться — да, а оперировать в памяти удобнее структурой. К тому же бизнес-логика сейчас редко работает с БД напрямую, как правило через ORM.

Кроме БД есть экранные формы, шаблоны отчётов, различные экспортные представления. Логично, что все они будут оперировать с одной и той же структурой — класом Account, а не друг с другом или с БД. Другими словами, не всегда класс Account может быть чисто внутренним делом модуля.
Re[4]: доступ к мемберам класса(getter'ы и setter'ы)
От: Desert Dragon Россия  
Дата: 21.03.11 12:05
Оценка:
Здравствуйте, andrey_nado, Вы писали:

_>Если какой-нибудь интерфейсный метод принимает 20 штук параметров, их естественно поместить в структуру. А отсюда уже недалеко и до простого класса с геттерами и сеттерами.


20 параметров — это уже получается загрузка данных из БД. Значит идем дальше.

DD>>Да и то, указанные данные по-хорошему должны хранится в реляционной базе данных, а не в классе Account.

_>Храниться — да, а оперировать в памяти удобнее структурой. К тому же бизнес-логика сейчас редко работает с БД напрямую, как правило через ORM.

Вот мы и подошли к новому руслу дискуссии
То что обсуждаемый анти-паттерн является одной из основ ORM, не о нем хорошо говорит, а об ORM плохо. Еще одно доказательство что ORM, это болото современного программирования, к кошерному ООП отношения не имеет так же как и гет/сет.

_>Кроме БД есть экранные формы, шаблоны отчётов, различные экспортные представления.


GUI для ввода данных и отчетов — это как раз тот самый случай, когда гет/сет в классе это основная функция класса.
А экспортные представления, это разве уже не БД ?
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 21.03.11 12:45
Оценка:
Здравствуйте, Desert Dragon, Вы писали:


DD>То что обсуждаемый анти-паттерн является одной из основ ORM, не о нем хорошо говорит, а об ORM плохо. Еще одно доказательство что ORM, это болото современного программирования, к кошерному ООП отношения не имеет так же как и гет/сет.

А что за анти-патерн?
ORM — болото? если с точки зрения asm то да, да и если так судить то все фреймворки, миддлваре это болото.
что такое кошерное ООП?

http://ru.wikipedia.org/wiki/ORM

ORM (англ. Object-relational mapping, русск. Объектно-реляционное отображение) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных».

я не волшебник, я только учусь!
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: Desert Dragon Россия  
Дата: 21.03.11 13:21
Оценка:
Здравствуйте, IROV.., Вы писали:

IRO>А что за анти-патерн?


Геттеры/сеттеры вестимо.

IRO>ORM — болото? если с точки зрения asm то да, да и если так судить то все фреймворки, миддлваре это болото.


"ORM is the Vietnam of Computer Science"
http://rsdn.ru/forum/philosophy/1980732.flat.aspx
Автор: IB
Дата: 29.06.06

Кстати похожие на на нашу дискуссию доводы с обеих сторон.

IRO>что такое кошерное ООП?


То, которое приводит к упрощению, а не усложнению архитектуры. И которое не вводит заблуждение, скрывая существенную сложность.
Можно даже попробовать определить какой-нибудь простой тест на кошерность, например:
Если после применения ООП, кода не стало меньше или какая-либо его часть стала менее понятна или производительность упала — значит это не кошерный ООП.
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 21.03.11 14:08
Оценка:
Здравствуйте, Desert Dragon, Вы писали:

DD>"ORM is the Vietnam of Computer Science"

DD>http://rsdn.ru/forum/philosophy/1980732.flat.aspx
Автор: IB
Дата: 29.06.06

DD>Кстати похожие на на нашу дискуссию доводы с обеих сторон.
Значит не все так плохо

IRO>>что такое кошерное ООП?


DD>То, которое приводит к упрощению, а не усложнению архитектуры. И которое не вводит заблуждение, скрывая существенную сложность.

ORM разве не делает это?
Просто понимаешь, многие люди которые повидали на своем свете, начинают гнать на языки/техники/решения высокого уровня, только потому что они не могут туда воткнуть "asm"(или еще чтото), но они никогда не задумываються а оно надо?
Конечно бывают кривые реализации, на которые обычно и аппелируют.
И естествено что этим "фламастером" нельзя разрисовать весь мир, тут нужно всегда смотреть, на 100% ли процентов удовлетворяет это решение, твоим запросам? И если нет, то лучше не связываться.

DD>Можно даже попробовать определить какой-нибудь простой тест на кошерность, например:

DD>Если после применения ООП, кода не стало меньше или какая-либо его часть стала менее понятна или производительность упала — значит это не кошерный ООП.
"Производительность упала", это не критерий ООП, почти все Патерны вводять упрощение кода, за счет потери в производительности.
И это нормально.
я не волшебник, я только учусь!
Re[5]: доступ к мемберам класса(getter'ы и setter'ы)
От: andrey_nado  
Дата: 21.03.11 15:54
Оценка:
Здравствуйте, Desert Dragon, Вы писали:

DD>GUI для ввода данных и отчетов — это как раз тот самый случай, когда гет/сет в классе это основная функция класса.


Ну то есть вы согласны с тем, что существуют классы — публичные! — у которых основная функция — хранить данные и предоставлять интерфейс гет/сет? Я только про это и говорил.
Re[6]: доступ к мемберам класса(getter'ы и setter'ы)
От: Desert Dragon Россия  
Дата: 22.03.11 06:47
Оценка:
Здравствуйте, andrey_nado, Вы писали:

DD>>GUI для ввода данных и отчетов — это как раз тот самый случай, когда гет/сет в классе это основная функция класса.


_>Ну то есть вы согласны с тем, что существуют классы — публичные! — у которых основная функция — хранить данные и предоставлять интерфейс гет/сет? Я только про это и говорил.


Отнюдь
Это будут внутренние классы. Публичный класса максимум может предоставлять базовый интерефейс, с методами вида GetData/SetData. А не доступ к конкретным полям.
Re[7]: доступ к мемберам класса(getter'ы и setter'ы)
От: IROV..  
Дата: 22.03.11 07:59
Оценка:
Здравствуйте, Desert Dragon, Вы писали:

DD>Отнюдь

DD>Это будут внутренние классы. Публичный класса максимум может предоставлять базовый интерефейс, с методами вида GetData/SetData. А не доступ к конкретным полям.
А как GUI достучиться до внутрених классов?
Гдето ты подменил понятие.

В бизнес логике, и всяких адаптерах, get|set это нормальная практика
я не волшебник, я только учусь!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.