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

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

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

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

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

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

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

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

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

Ты, судя повсему, закончил как-раз на ней.

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

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

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

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

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

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

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

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

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

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

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

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

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

Или ты хотел сказать чтото совсем другое а мы "Тролли" тебя не понимаем?

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 как хороший пример ООП. Это плохой пример, негодный
Негодный, это я тебе тоже написал выше

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

ололо

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

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


DD>Вот для того что бы не возникало подобных споров я и хочу уточнить термин инкапсуляции. Из-за расплывчатого толкования которого и возникет усложнение архитектуры при применении ООП, вместо упрощения.
Я тебя обрадую наш спор, не о инкапсуляции как высшей материи, а просто о техническом приеме "почему get|set круче pure members" а про ООП я уже выше писал что повальный get|set на все мемберы там не должно быть, но бывают, и если бывают то только через get|set

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

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

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

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

Просто некоторые зляться, а некоторые так

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

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

ИМХОб всегда считалось хорошим тоном разделять биснес логику и работу с базой(хранилищем). Поэтому странно иметь в бизнес логике код с методами "адекватно отражающими работу с БД (с)".

Ytz>Молодец, что спросил
Антипример.

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

Ytz> if (PortAlreadyInUse(port))
А это вообще неверно. Может, сейчас порт in use, а ко времени коннекта станет свободен?

Ytz>Выбрав второй вариант тебе будет удобно писать connection.Port_ -= 20
А может, это будет допустимо на целевой архитектуре? В общем, пока не убедил.

Здравствуйте, 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>А может, это будет допустимо на целевой архитектуре? В общем, пока не убедил.

Я и не старался В любом случае это просто иллюстрация.

Здравствуйте, 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 это не ООП это просто техника скрытия реализации.

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

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

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

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

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

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

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

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

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

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

struct Point
{
    int X;
    int Y;
};

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

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

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

Кстати, Джаззер, лихо начав, потом вполне корректно пояснил свою мысль

Автор: jazzer
Дата: 04.03.11

, не оставив предмета для возражений.

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

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

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

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

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

Кстати там выше уже ответили, да и почитал про "исправление" своей мысли твоего джаззера

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

IRO>потомучто mulSize это не ООП это просто техника скрытия реализации.
Сегодня чисто случайно узнал что это называеться — "Лазанья", уже забыл кто сказал

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

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

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

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

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