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

J>

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

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

o.sort();

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

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

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

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

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

J>вместо
J>

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

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

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

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

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

и т.п.

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

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

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

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

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

std::vector<Age> v;

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

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

Здравствуйте, 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_;
};

Так ведь? Иначе как ты проверишь корректность устанавливаемых значений?

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);

Где следить за значением ?

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 алгоритмы приделывать, которые могут понадобится?

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

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

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

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

Вот теперь понял, возражений нет

А есть ли возможность генерировать автоматически:

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

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

Такой код

c.value = 1;

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

с.SetValue( 1 );

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

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

On 04.03.2011 16:02, jazzer wrote:

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

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

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

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

Я тоже так думал когда то. Структуры + методы. Но тот же личный опыт всё таки подсказывает что это не очень правильно. Местами конечно можно, но обычно такой подход чреват печальными последствиями. Структуры имеют свойство разрастаться. Код, меняющий данные, расплывается по проекту. Со временем становится всё трудней определять "в каком же месте это значение устанавливаетя". Использование аксессоров дает такой бонус, как простота отслеживания доступа на запись. Зачастую сеттеры вообще бывают не нужны, все значения могут устанавливаться в каком нибудь одном методе вроде конструктора или ф-ции initialize (ну или не все значения, но по крайней мере связные группы точно). Убрал всё в приват и можешь быть уверен, что просто так изменить данные никто не сможет, инкапсуляция — великая вещь. Ну и просто некрасиво выглядит доступ, если имена членов как либо синтаксически выделены, конструкции вида object.member_ = xxx режут глаз. Метод, использующий большое количество сеттеров намекает на возможность рефакторинга в виде переноса кода в метод класса.
Ортогонализация рулит, а аксессоры — способ следования правилу Деметры. А в соседнем посте приведён явный пример того, во что может превратиться код если ему не следовать:

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

Здравствуйте, 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);

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

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

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

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

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

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

M>

M>Point p;
M>

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

как это все напоминает цитату "костыли для рожденных ползать" из статьи "C++ vs. C#"
http://vydrov.com/index.php/archives/128
с чего бы это ткие ассоцтиации ? лично у меня с того что вижу как люди придумывают фееричный бред про безопасность совершенно излишнюю в большинстве случаев ИМХО

Здравствуйте, 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, что изменится?

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

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

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

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

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

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

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

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

MZ>On 04.03.2011 16:02, jazzer wrote:

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

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

Ну тут у нас все это заложено в систему сразу (так как иcпользуем QT), так что все нормально, интерфейс такой.

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

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

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

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

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

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

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

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

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

Вода-вода, приведи пример, уважаемый.