Re[14]: Изменения в MFC 7.0/7.1 - MFC

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

T>Вопрос в том кто в этом виноват. Я отнюдь не вхожу стройные ряды пинателей мелкомягких, но всё же думаю что в данном случае они поступили не совсем разумно.

Они объединили два класса (CString и STL строку) в один. Мне кажется, это разумно. Зачем иметь два класса, представляющих одно и то же?

T>В MFC десятки открытых атребутов. Найдите в MSDN указатель "Data members" и посмотрите список классов за ним. Как же вы пользуетесь необъектноориентированной библиотекой? Может напишите в Microsoft, расскажите что их код не может считаться ОО и попросите прислать вам апгрейд?

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

T>На счёт примера. Скажем некоторые методы класса выполняют некоторые расчёты или операции другого рода. При этом они используют некоторые параметры, которые явяляются достаточно постоянными и не требующими частого изменения,что делает разумным хранение этих параметров в данных объкта класса (причиной так же может быть необходимость передача этих параметров в другие, возможно скрытые, методы). При этом эти параметры не имеют ограничение на значение или проверка этих значений не имеет смысла и гораздо эффективнее обойтись скажем ASSERT-ом, который можно разместить в вызывающей процедуре (в сущности какая разница где глюк обнаружится). Какой смысл делать GetSet-ы?
T>Вот в MFC например валидность многих хендлов проверяеться (ASSERT-ом) непосредственно перед операциями с нимию.

Если у вас private переменная, которая не видна извне и используется только внутри, никаих GetSet делать, конечно, не надо. Но ведь речь не об этом. Речь о дотупе к переменной извне. Если же вам нужен доступ к переменной извне, то делать GetSet предпочтительнее, чем делать переменную public.

T>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы

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

T>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него).

Следствие низкой квалификации разработчиков?

S>>При чем тут кит? MDSN является документацией.
T>Я всё же наставиваю на том, что протокол класса являеться документом.
Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут.

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

V>Если открытый атрибут — его будут использовать и это очевидно.
CString::m_pchData не есть открытый атрибут.

V>Во всяком случае плохо что микрософт открыто не опубликовала список рпоблем и их решений,
Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?

S>Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?

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

Если неквалифицированные могли написать успешно компитлируемый код — то проблема очевидна:
политика безопастности простым видом не использовалась корректно самой Микрософт.

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

S>>Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?

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

Хм. Какое интересно определение открытости.
Определимся в терминологии?
Я считаю, что когда мы говорим "Открытый" — мы имеем ввиду, что он объявлен с ключевым словом public. А каково ваше определение "открытости"?

V>Если неквалифицированные могли написать успешно компитлируемый код — то проблема очевидна:
V>политика безопастности простым видом не использовалась корректно самой Микрософт.
Написание успешно компилируемого кода не есть признак квалификации.
Ну, и соответственно вывод об очевидной проблеме неверен, потому что следует из неверного положния.

S>Я считаю, что когда мы говорим "Открытый" — мы имеем ввиду, что он объявлен с ключевым словом public. А каково ваше определение "открытости"?

мое, то же, но с учетом private, для наследования,
в данном случае это не играет роли — никто не наследовал.
Значит если не public -значит ошибка должна быть, выдаваться компилятором,
либо полностью законное использование, особенно в неквалифицированных случаях.

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

Написание компилятора и библиотеки, который не ругается на неквалифицированное использование
и говорит что все в порядке — "свидетельство неквалификации".

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

S>>Я считаю, что когда мы говорим "Открытый" — мы имеем ввиду, что он объявлен с ключевым словом public. А каково ваше определение "открытости"?

V>мое, то же, но с учетом private, для наследования,
V>в данном случае это не играет роли — никто не наследовал.
Играет. Наследование имело место быть.
Речь шла о то, что некто унаследовался от CString, напрямую использовал m_pchData, при переходе на Visual 7 код перестал компилироваться, потому что в новой CString переменной m_pchData нету

V>Значит если не public -значит ошибка должна быть, выдаваться компилятором,
V>либо полностью законное использование, особенно в неквалифицированных случаях.
"Полностью законным" может считаться только использование документированных функций и переменных. Все остальное — под вашу ответственность, на ваш страх и риск. CString::m_pchData в MDSN не упоминается как член класса CString.

V>Написание компилятора и библиотеки, который не ругается на неквалифицированное использование
V>и говорит что все в порядке — "свидетельство неквалификации".
Типа "во всех моих ошибках виноват кто угодно, но только не я сам"?
А использование напрямую CString::m_pchData однозначно считаю ошибкой.
Компилятор не брался вас учить программированию. Это должны были сделать в институте.

Можно вообще написать в начале stdafx.h


#define private public
#define protected public

и радоваться жизни. Авторы Ultimate Toolbox такого еще не придумали. Будет на самом деле — Ultimate!

Смысл этого в том, что наследоваться от CString в ясном уме и твердой памяти никто не будет.

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

В явном виде портите себе жизнь -нарушаете безопастность.
Жаловаться придется на себя,

а наследование — типичный прием

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

al>Можно вообще написать в начале stdafx.h

al>


al>#define private public
al>#define protected public

al>

Не поможет. Откомпилируется, но не слинкуется. protected и private функции вроде не экспортируются, хотя, может быть, я и неправ.

al>Смысл этого в том, что наследоваться от CString в ясном уме и твердой памяти никто не будет.
Почему нет? Вполне. Важно, чтобы в наследнике вы использовали только документированные функции — это сделает вашу жизнь легкой и радостной.
А насчет зачем это надо:
Например, у вас есть DLL, в ней куча ресурсов строк. Когда вы вызываете LoadString, надо переключать ресурсы. Стандартный LoadString этого не делает. Чтобы избежать постоянного повтора кода переключения ресурсов, я наследуюсь и пишу свой LoadString, который переключает ресурсы прежде чем строку из ресурсов грузить. Класс мой называется CString4MyDLL. И что со мной не так? Ум не ясен или память не тверда? И каково было бы ваше решение?

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

T>>На счёт примера. Скажем некоторые методы класса выполняют некоторые расчёты или операции другого рода. При этом они используют некоторые параметры, которые явяляются достаточно постоянными и не требующими частого изменения,что делает разумным хранение этих параметров в данных объкта класса (причиной так же может быть необходимость передача этих параметров в другие, возможно скрытые, методы). При этом эти параметры не имеют ограничение на значение или проверка этих значений не имеет смысла и гораздо эффективнее обойтись скажем ASSERT-ом, который можно разместить в вызывающей процедуре (в сущности какая разница где глюк обнаружится). Какой смысл делать GetSet-ы?
T>>Вот в MFC например валидность многих хендлов проверяеться (ASSERT-ом) непосредственно перед операциями с нимию.

S>Если у вас private переменная
Ну ё мой, я уже психовать начинаю, ну какая нафиг private

, мы уже третий день про открытые атрибуты базарим а вы мне private ... ну хоть немного надо уважать собеседника.
, которая не видна извне и используется только внутри, никаих GetSet делать, конечно, не надо. Но ведь речь не об этом. Речь о дотупе к переменной извне. Если же вам нужен доступ к переменной извне, то делать GetSet предпочтительнее, чем делать переменную public.

Ну нафига:

.......
private: 
  int m_Val;
public:  
  inline int GetVal()
  {
     return m_Val;
  };

  inline void SetVal(int Val)
  {
     m_Val=Val;
  };
.......

Вместо:

.......
public:
   m_Val; 
.......

T>>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы

S>Ради хорошего стиля я именно так и делаю. Но повторюсь, функции GetSet добавляются обычно когда нужен доступ к переменной извне. Ко всяким внутренним флажкам и т.д. доступ обычно напрямую.
Ну неужели я так на дурака похож?

S>"Хороший стиль" — это очень важно.
"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.

T>>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него).

S>Следствие низкой квалификации разработчиков?
Да, напиши об этом, майкрасофту, борланду или ещё кому нть. Да же в MSDN туча примеров с goto. А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить

.

S>Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут.
Они такими и задумывались

.

И вообще спросите у любого профессионального программера на VC. Почти любой скажет что лучшая документация по MFC это её исходники.

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

S>>Если у вас private переменная
T>Ну ё мой, я уже психовать начинаю, ну какая нафиг private

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

T>Ну нафига:
T>

T>.......
T>private: 
T>  int m_Val;
T>public:  
T>  inline int GetVal()
T>  {
T>     return m_Val;
T>  };

T>  inline void SetVal(int Val)
T>  {
T>     m_Val=Val;
T>  };
T>.......
T>

T>Вместо:

T>

T>.......
T>public:
T>   m_Val; 
T>.......
T>

1. Чтобы не позволять ставить переменной невалидные значения

void SetVal(int Val)
{
АССЕРТ(Val >= 0);
m_Val=max(0, Val);
};

2. Чтобы гарантрировать, что используемя Val всегда валидна.

int GetVal()
{
АССЕРТ(m_Val >= 0);
return max(m_Val, 0);
};

3. Чтобы точку прерывания было где поставить.
А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания?
А так — в одно месте:
void SetVal(int Val)
{
АССЕРТ(Val != 666);
m_Val=max(0, Val);
};
И вас ASSERT уведомит, что птичка поймалась.

4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения.
Я делаю изменение только в одном месте:
int GetVal()
{
АССЕРТ(m_Val >= 0);
return max(m_Val, 0)/2;
};

А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите.

Считаю, что этих 4-х причин достаточно, чтобы написать Set и Get функции.

T>>>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы

S>>"Хороший стиль" — это очень важно.
T>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.
А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу

T>>>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него).
S>>Следствие низкой квалификации разработчиков?
T>Да, напиши об этом, майкрасофту, борланду или ещё кому нть.
Зачем? Они меня не спрашивают и сами это отлично понимают.

T>Да же в MSDN туча примеров с goto.
Следствие низкой квалификации писателей MSDN?
MSDN пишут такие же люди, как мы с вами. Я так понимаю, вы, если бы MDSN писали, написали бы примеры с goto, а потом мне кто-нибудь на этом форуме на это бы указывал. Круг замкнулся. Примеры с goto появляются в MSDN потому что писатели MSDN не считают это неправильным, а oни не считают это неправильным потому что даже MDSN содержит примеры с goto.

T>А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить

.
Самое простое и надежное — флажок выставить.

S>>Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут.
T>Они такими и задумывались

.
Интересно, а что тогда в книге Undocumented Windows написано? Ведь все функции, которые там упоминаются, есть в H файлах, иначе бы у вас проект не собрался? Не находите, что ваше определение докумантации немного противиречит общепринятому?

T>И вообще спросите у любого профессионального программера на VC. Почти любой скажет что лучшая документация по MFC это её исходники.

Это для красного словца. Источник информации — да. Источник новых знаний — да. Но никак не документация. Документация -это MSDN.

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

T>>Ну нафига:
T>>

T>>.......
T>>private: 
T>>  int m_Val;
T>>public:  
T>>  inline int GetVal()
T>>  {
T>>     return m_Val;
T>>  };

T>>  inline void SetVal(int Val)
T>>  {
T>>     m_Val=Val;
T>>  };
T>>.......
T>>

T>>Вместо:

T>>

T>>.......
T>>public:
T>>   m_Val; 
T>>.......
T>>

S>1. Чтобы не позволять ставить переменной невалидные значения

S>void SetVal(int Val)
S>{
S>АССЕРТ(Val >= 0);
S>m_Val=max(0, Val);
S>};

S>2. Чтобы гарантрировать, что используемя Val всегда валидна.

S>int GetVal()
S>{
S>АССЕРТ(m_Val >= 0);
S>return max(m_Val, 0);
S>};

Ну я же писал об этом в предыдущих письмах. Не всегда есть ограничения на значения, зачем передёргивать 8ой раз (в данном случае к стате достаточно было сделать данные беззнаковыми). Иногда, даже если проверка нужна, гораздо разумнее делать её в месте использования данных, как и делаеться в MFC. (в общем всё это я уже писал)

S>3. Чтобы точку прерывания было где поставить.
S>А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания?

S>А так — в одно месте:
S>void SetVal(int Val)
S>{
S>АССЕРТ(Val != 666);
S>m_Val=max(0, Val);
S>};
S>И вас ASSERT уведомит, что птичка поймалась.
Привер явно надуман. Возможно если будет такой маразматический код, то я и зделаю метод, но это 1 из 1000.

S>4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения.
S>Я делаю изменение только в одном месте:
S>int GetVal()
S>{
S>АССЕРТ(m_Val >= 0);
S>return max(m_Val, 0)/2;
S>};
Это не подпадает под описанный выше случай. Тут есть явная обработка данных перед выдачей, и вдруг это захотеться не может. Если это вдруг захочеться, то разработчику надо будет намылить лысину.

S>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите.

А Replace на что

.

T>>>>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы

S>>>"Хороший стиль" — это очень важно.
T>>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.
S>А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу
Извините за некоторую грубость, но никакой идиот не будет ставить даже 10 таких строчек. Я описывал по вашей прозьбе конкретный пример, а вы тут кучу если. Тока я не понял чем SetGet от "=" отличаеться?

T>>>>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него).
S>>>Следствие низкой квалификации разработчиков?
T>>Да, напиши об этом, майкрасофту, борланду или ещё кому нть.
S>Зачем? Они меня не спрашивают и сами это отлично понимают.

T>>Да же в MSDN туча примеров с goto.
S>Следствие низкой квалификации писателей MSDN?
S>MSDN пишут такие же люди, как мы с вами. Я так понимаю, вы, если бы MDSN писали, написали бы примеры с goto, а потом мне кто-нибудь на этом форуме на это бы указывал. Круг замкнулся. Примеры с goto появляются в MSDN потому что писатели MSDN не считают это неправильным, а oни не считают это неправильным потому что даже MDSN содержит примеры с goto.

T>>А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить

.
S>Самое простое и надежное — флажок выставить.

S>>>Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут.
T>>Они такими и задумывались

.
S>Интересно, а что тогда в книге Undocumented Windows написано? Ведь все функции, которые там упоминаются, есть в H файлах, иначе бы у вас проект не собрался? Не находите, что ваше определение докумантации немного противиречит общепринятому?

T>>И вообще спросите у любого профессионального программера на VC. Почти любой скажет что лучшая документация по MFC это её исходники.

S>Это для красного словца. Источник информации — да. Источник новых знаний — да. Но никак не документация. Документация -это MSDN.

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

T>Ну я же писал об этом в предыдущих письмах. Не всегда есть ограничения на значения,

Не всегда. Но они могут появлятся, когда программа уже написана и сдана. (Пример см. ниже) А ваша задача — заложить возможность легкого изменения с самого начала. Set/Get функции эту возможность закладывают.

T>зачем передёргивать 8ой раз

Это всего лишь пример. Проверка может быть сколь угодно сложной.

T>(в данном случае к стате достаточно было сделать данные беззнаковыми). Иногда, даже если проверка нужна, гораздо разумнее делать её в месте использования данных, как и делаеться в MFC. (в общем всё это я уже писал)

А если код проверки валидности значения занимает десять строк? Будте 10 линий кода везде копировать?

S>>3. Чтобы точку прерывания было где поставить.
S>>А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания?
S>>А так — в одно месте:
S>>void SetVal(int Val)
S>>{
S>>АССЕРТ(Val != 666);
S>>m_Val=max(0, Val);
S>>};
S>>И вас ASSERT уведомит, что птичка поймалась.
T>Привер явно надуман. Возможно если будет такой маразматический код, то я и зделаю метод, но это 1 из 1000.

Что значит надуман? Такое случается сплошь и рядом. Вы смотрите в отладчике, а у вас переменная имеет какое-то левое значение. "Ах ты ж ексель-моксель, когда она успела его получить?" Как искать предполагаете, с вашими двумя сотнями m_Val=ххх, разбросанными по всему коду?

S>>4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения.
S>>Я делаю изменение только в одном месте:
S>>int GetVal()
S>>{
S>>АССЕРТ(m_Val >= 0);
S>>return max(m_Val, 0)/2;
S>>};
T>Это не подпадает под описанный выше случай. Тут есть явная обработка данных перед выдачей, и вдруг это захотеться не может.

Почему не подпадает? Вы спросили, какие преимущества у Set/Get против public переменной. Данный пункт иллюстрирует гибкость Set/Get, которой нет у public переменной.

T>Если это вдруг захочеться, то разработчику надо будет намылить лысину.

Простой пример. Вам выдали спецификации. Вы написали программу, версию 1. Протестировали. Сдали. Все довольны. Дальше переходим к версии два. Выдаются спецификации, и тут вы видите, что, чтобы им соответствовать, надо везде поделить m_Val на два. Это называется "вдруг захотелось", не так ли? Такое возможо? При многолетнем контракте — вполне. Кто разработчик? Вы. Вам придется самому себе лысину мылить. А чтобы такого не было, надо придерживаться такого стиля, который бы позволил с заданиями легко и быстро справляться. Что я и делаю и вам советую.

S>>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите.
T>А Replace на что

.

Наделаете ошибок при Replace. Гарантирую.

T>>>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.
S>>А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу
T>Извините за некоторую грубость, но никакой идиот не будет ставить даже 10 таких строчек.

Я надеюсь. А то же тогда делать, если ваша переменная public, ей присвивается значение в 200 местах и где-то в каой-то момент ей присваивается невалидное значение? Как отлавливать будете?

T>Я описывал по вашей прозьбе конкретный пример, а вы тут кучу если.

Так ведь программа — она в развитии. "Если" — это все те проблемы, с которыми вы столкнетесь рано или поздно, если над одним проектом будете работать долго.

T>Тока я не понял чем SetGet от "=" отличаеться?
Возможностью легкой модификации кода в одном месте без ненужного дублирования кода. Облегчением процесса отладки.

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

V>Здесь вы перешли в плоскость субективности и личных впечатлений
Что конкретно субъективно и является личным впечатлением?

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

А вот приватная переменная и ее изменение — и недокументирование этого,
это тихая подставка.

сообщение типа"мне КАЖЕТСЯ" -"Я считаю".

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

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

document.window.line.symbol -лучше обращение.

в обще для немного важных вещей -надо вставлять.
Для абсолютно всего — кажется лишним.

T>>Ну я же писал об этом в предыдущих письмах. Не всегда есть ограничения на значения,

S>Не всегда. Но они могут появлятся, когда программа уже написана и сдана. (Пример см. ниже) А ваша задача — заложить возможность легкого изменения с самого начала. Set/Get функции эту возможность закладывают.
Да ничего не может появиться. Вы просили конкретный пример, я как мог описал ситуацию. В ней по сути даже не требуеться чтение атребута. Заложить можно всё что угодно.

T>>зачем передёргивать 8ой раз

S>Это всего лишь пример. Проверка может быть сколь угодно сложной.
Опять 25. Да, это конечно это всего лишь пример, ну так что и требовалось, я же не говорю что нужно всегда применять открытые атребуты, это глупо, если действительно нужна проверка или ещё какеи либо действия при установки, чтении данных то без Set/Get не обойтись. Я всего лишь протестовал против того, что повление открытого атрибута делает код не ОО и всё.

T>>(в данном случае к стате достаточно было сделать данные беззнаковыми). Иногда, даже если проверка нужна, гораздо разумнее делать её в месте использования данных, как и делаеться в MFC. (в общем всё это я уже писал)

S>А если код проверки валидности значения занимает десять строк? Будте 10 линий кода везде копировать?
Нет, я напишу функцию или макрос. И потом валидность многих данных может меняться со временем (пример — хендлы) и потому перед использованием их всё равно нужно проверять.

S>>>3. Чтобы точку прерывания было где поставить.
S>>>А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания?
S>>>А так — в одно месте:
S>>>void SetVal(int Val)
S>>>{
S>>>АССЕРТ(Val != 666);
S>>>m_Val=max(0, Val);
S>>>};
S>>>И вас ASSERT уведомит, что птичка поймалась.
T>>Привер явно надуман. Возможно если будет такой маразматический код, то я и зделаю метод, но это 1 из 1000.

S>Что значит надуман? Такое случается сплошь и рядом. Вы смотрите в отладчике, а у вас переменная имеет какое-то левое значение. "Ах ты ж ексель-моксель, когда она успела его получить?" Как искать предполагаете, с вашими двумя сотнями m_Val=ххх, разбросанными по всему коду?
У меня такого не случаеться. Я не себе такой код не представляю, ну то есть не писал никогда. И потом повторяю в 10ый раз, был приведён конкретный пример, показывающий лишь то, что бываюьт ситуации, когда закрывать данные не имеет смысла.

S>>>4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения.
S>>>Я делаю изменение только в одном месте:
S>>>int GetVal()
S>>>{
S>>>АССЕРТ(m_Val >= 0);
S>>>return max(m_Val, 0)/2;
S>>>};
T>>Это не подпадает под описанный выше случай. Тут есть явная обработка данных перед выдачей, и вдруг это захотеться не может.

S>Почему не подпадает? Вы спросили, какие преимущества у Set/Get против public переменной. Данный пункт иллюстрирует гибкость Set/Get, которой нет у public переменной.
В 11 раз повторяю, про конкретны пример, когда это не нужно. Я могу привести ещё сотнбю примеров когда инкопсуляция необходима, но зачем? Я всего лишь говорю что она не обязательна.

T>>Если это вдруг захочеться, то разработчику надо будет намылить лысину.

S>Простой пример. Вам выдали спецификации. Вы написали программу, версию 1. Протестировали. Сдали. Все довольны. Дальше переходим к версии два. Выдаются спецификации, и тут вы видите, что, чтобы им соответствовать, надо везде поделить m_Val на два. Это называется "вдруг захотелось", не так ли? Такое возможо? При многолетнем контракте — вполне. Кто разработчик? Вы. Вам придется самому себе лысину мылить. А чтобы такого не было, надо придерживаться такого стиля, который бы позволил с заданиями легко и быстро справляться. Что я и делаю и вам советую.

В 12 ый раз ...

S>>>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите.
T>>А Replace на что

.

S>Наделаете ошибок при Replace. Гарантирую.
Вообще то это была шутка, но гарантии здесь не уместны.

T>>>>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.
S>>>А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу
T>>Извините за некоторую грубость, но никакой идиот не будет ставить даже 10 таких строчек.

T>>Я описывал по вашей прозьбе конкретный пример, а вы тут кучу если.

S>Так ведь программа — она в развитии. "Если" — это все те проблемы, с которыми вы столкнетесь рано или поздно, если над одним проектом будете работать долго.

T>>Тока я не понял чем SetGet от "=" отличаеться?
S>Возможностью легкой модификации кода в одном месте без ненужного дублирования кода. Облегчением процесса отладки.
Мы же о пухлости говорили про какие то 16:1. Эт то тут причём.

	От:	Serguei666
	Дата:	02.06.03 14:35
	Оценка:

	От:	Serguei666
	Дата:	02.06.03 14:43
	Оценка:

	От:	vgrigor
	Дата:	02.06.03 14:50
	Оценка:

	От:	Serguei666
	Дата:	02.06.03 15:06
	Оценка:

	От:	vgrigor
	Дата:	02.06.03 15:16
	Оценка:

	От:	tyomchick
	Дата:	03.06.03 09:16
	Оценка: