я выше привёл пример инварианта, нарушаемого таким подходом

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

class SquareRect{ 
public: 
    SquareRect(const double width, const double height) { 
        //show deprecation warning
        //check wich one is preferrable:
        //assert(width==height) or
        //side_length_ = max(width, height) or
        //side_length_ = min(width, height) or
        //side_length_ = 0
   } 

    SquareRect(const double side_length) :
        side_length_(side_length) { }
 
    double getWidth() const { return side_length_; } 
    void setWidth(const double width) { 
        //show deprecation warning
        //do nothing or call resize(width) if needed
    } 
 
    double getHeight() const { return side_length_; } 
    void setHeight(const double height) { 
        //show deprecation warning
        //do nothing or call resize(height) if needed    
    }

    void resize(const double side_length){
        //do some checks here
        side_length_ = side_length;
    }

private: 
    double side_length_; 
}; 
 
int main() 
{ 
    NewRect b(2, 2); 
 
    b.setWidth(5); 
    b.setHeight(1); 
 
    assert(square(a) == 5); 
... 
}

вот теперь я понял, что tailgunner действительно толстый тролль ;)

потому, что я давно бы уже на его месте сломался, еще точнее и
не начинал бы. а он все пытается обьяснить очевидные вещи.

get/set всегда и «на всякий случай» - это, мне кажется, идиотизм.
вот два расхожих заклинания:

1. я не в состтянии «правильно» спроектировать код сразу,
он, наверное, будет меняться потом, и пути этих изменений
неисповедимы.

это верно. никто не может. другое дело, что никто так честно не
формулирует ;)

2. а вот я постелю здесь соломки, и менять будет легко и
приятно.

да вот хрен там. по сравнению с другими, действительно болезненными
и нетривиальными переделками - а они будут нужны обязательно в любом
«интересном» проекте - исправление ошибок компиляции (мы ведь можем
рассчитывать на компилятор, правда?) - это просто... ну, даже не знаю.

ps. никто, ессно, не говорит, что они не нужны НИКОГДА.

Ж)

mixin == дополнительная функциональность.
properties == см. спецификацию JavaBeans.
лямда == анонимный класс.

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

зря ты не попробовал хотя бы скомпилировать этот код (откуда NewRect в main?). инвариант по-прежнему нарушается (что логично)

Чувствую чт озашел в магазин костылей и инвалидных колясок.

в контексте проблемы автора, какие ещё есть варианты, кроме immutable объекта и открытых полей?

интерфейс, не содержащий сущностей предыдущего уровня абстракции: стек не предоставляет наверх геттер/сеттер для агрегируемого контейнера - он предоставляет интерфейс стека, не имеющий завязок на конкретную реализацию

бонусы от геттеров/сеттеров на этом не заканчиваются

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

> get/set всегда и «на всякий случай» - это, мне кажется, идиотизм.

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

откуда NewRect в main

не тупи

int main()  
{  
    SquareRect b(2, 2);  
  
    b.setWidth(5);  
    b.setHeight(1);  
  
    assert(square(a) == 5);  

    //...  

    return 0;
}

зря ты не попробовал хотя бы скомпилировать этот код

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

инвариант по-прежнему нарушается (что логично)

ты ещё не ответил на справедливый вопрос белки о различиях прямоугольника и квадрата

как я понял, что твоя идея состоит в том, чтобы у нас были открытые поля, и отдельный класс figureUtils с методом square( squarrable * fig), в который бы возвращал значение площади?

Если да, то ты привёл отличный пример победы над одной из возможностей сеттеров.

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

судя по приведённому коду, получается не очень

ты ещё не ответил на справедливый вопрос белки о различиях прямоугольника и квадрата

то есть добиться совместимости ты не можешь? нахрен тогда было пыжиться?

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

неправильно понял

хорошо сливаешь :)

хорошо сливаешь :)

код будет или нет?

код будет или нет?

какой тебе ещё код нужен?

1). интерфейсы это хорошо, это круто. Но сеттеры и геттеры то тут при чём? Это немного ортогональные понятия и можно благополучно использовать и то и другое.

2).Ответ на вопрос о необходимости дополнительных уровней абстракции, ради того, что мы можем получить и без них неочевиден..

ну так пиши как правильно :) а то это не логично - написать пример кривой реализации и сказать, что так делать плохо :)

1) много продакшен языков позволяют описывать интерфейсы для полей классов?

2) вы писали в команде?

> Идиот тот, кто не понимает,

[... snip some «surely I know better» pathetic squeaks

или тот, кто не понимает, что необходимрсть get/set
при многопоточном доступе не обсуждается ?

речь-то ведь идет про «а вдруг понадобится» симптом.

ну, а в первую очередь, придурок тот, кто брызжет
категоричностью.

1). java умеет, шарп умеет, дельфя умеет с c++ никто не запрещает множественное наследование классов только с публичными виртуальными методами. нужно больше?

2). да, но опыта не много.

речь-то ведь идет про «а вдруг понадобится» симптом.

Понадобится. И даже не вдруг. Вон два горячих финских парня рассуждают про квадрат и прямоугольник - куда уж проще задача, даже и ошибаться-то негде, сесть, плюнуть и сделать? Ну так давай попросим их сделать такие тривиальные вещи, как:
1. Добиться совместимости по присваиванию - в любое место, куда может податься прямоугольник, может быть подан квадрат
2. Реализовать ограничение у «квадрата ширина и высота всегда одинакова»
3. Реализовать «положение объекта» как его левый-верхний-угол
4. Реализовать обратную связь, когда при изменении ширины, высоты или положения объекта он перерисовывается на экране
Это ведь нормальный жизненный цикл задачи - постепенное увеличение функциональности. И посмотрим, сумеет ли выкрутиться противник сеттеров-геттеров

java умеет, шарп умеет, дельфя умеет

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

да, но опыта не много.

Отдадите проект клиентам и откажетесь от дальнейшей поддержки и сопровождения или будете молится на мою аватару.

какой тебе ещё код нужен?

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

http://codepad.org/tDYwssty

t: t.cpp:52: int main(): Assertion `square(b) == 5' failed.

какое слово тебе непонятно?

И посмотрим, сумеет ли выкрутиться противник сеттеров-геттеров

Он умер когда я ему сказал что getHeight и getWidth должен возвращать одинаковые значения. А Вы только посмотрите какой инопланетный у него код - там высота квадрата равна нулю!

ну так пиши как правильно

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

избавление от геттеров/сеттеров здесь не означает вынос в public, если что

Вон два горячих финских парня

5.2

рассуждают про квадрат и прямоугольник

так может у тебя есть решение, любитель геттеров/сеттеров? ошибаться-то негде

>Вы знатно сметанировали, либо показали свою несостоятельность, ибо путаете классы и интерфейсы.

O'Rly? В каком же месте я её путаю?

Отдадите проект клиентам и откажетесь от дальнейшей поддержки и сопровождения или будете молится на мою аватару.

я где-то выше написал, что сеттеры/геттеры это плохо? :)

>И посмотрим, сумеет ли выкрутиться противник сеттеров-геттеров

Сумеет. Не сомневайся.

Интерфейс, видимый клиентам, необязательно должен имплементировать геттеры/сеттеры класса, с объектом которого клиенты работают. Тем не менее, клиенты будут работать с всегда валидным объектом.

интерфейсы это хорошо, это круто. Но сеттеры и геттеры то тут при чём?

при том, что они являются частью интерфейса

Это немного ортогональные понятия

нет

O'Rly? В каком же месте я её путаю?

Вам ссылку на ваш пост дать и на спецификацию явы, где для особо ударённых описано что интерфейс может иметь только методы и static final поля. Хотя учитвая Ваш опыт и категоричность, спецификацию Вы не читамши.

тяжело, понять, что хочет сказать человек, не высказывающий до конца свою точку зрения ;)

на эти ответы можно спросить только, а «сказать то ты что хотел?»

> так может у тебя есть решение, любитель геттеров/сеттеров? ошибаться-то негде

Прямоугольник -*наследование*-> Квадрат (Убиваем пункты 1 и 2)
Рефакторинг прямоугольника на предмет добавления вершины (убиваем пункт 3)
Рефакторинг прямоугольника на пердмет добавления листенеров (убиваем пунт 4)
При этом ни одна строчка коду, использующая прямоугольник или квадрат, даже не узнает о всей этой свистопляске. ЧТП (что и требовалось получить).

Реализуй без сеттеров в том или ином виде пункт 4. Ждем-с, да.

а сказать то хотел? я это как бы знамши

Прямоугольник -*наследование*-> Квадрат (Убиваем пункты 1 и 2)

это уже нарушение принципа подстановки Лисков, второй пункт так не убирается; либо приводи код, либо не пори чушь

При этом ни одна строчка коду, использующая прямоугольник или квадрат, даже не узнает о всей этой свистопляске

я там выше привёл инвариант: изменение площади прямоугольника. покажи код, в котором этот инвариант при переходе на квадрат не может быть нарушен (т.е. соблюдена поведенческая заменимость объектов)

> Прямоугольник -*наследование*-> Квадрат

oh. shit. Класс наследник накладывающий ограничения на класс прародитель..

мне не слово непонятно, мне непонятно почему ты тупо скопипастил код и надеешься что он заработает :) быдлокодер?

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

ищо?

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

point в том, что практически в любом случае когда setter
«внезапно „понадобился там, где не ожидалось при проектировании,
у нас гораздо больше проблем, чем просто поправить direct users.

вот давайте еще ВСЕГДА писать так, что любое изменение членов
класса происходит обязательно под per-instance семафором? да
ведь массу примеров можно придумать, когда при изменении
функциональности это вдруг станет действительно необходимо.

Вы вошли в режим шланга, как я погляжу, я с удовольствием ткну вас вашим гибким носом:

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

java умеет

и

интерфейс может иметь только методы и static final поля

я это как бы знамши

Говорят о расстройстве вашей психики, или том что Вы таки сейчас вещает из лужи, и будете выкручиваться.

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

10x :) я начисто проингорировал слова «для полей классов». Согласен в луже посидел, мокро и не приятно.

К слову, я специально и писал, про при наличии г/с у нас всё ок с наследованием интерфейсами. ссылк: http://www.linux.org.ru/jump-message.jsp?msgid=4708731&cid=4711057

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

Культ карго в чистом виде.

> почему ты тупо скопипастил код и надеешься что он заработает :)

Не думаю, что он надеялся. ))

быдлокодер?

Автор этого кода? Разумеется. )))

по делу есть что сказать?

По делу всё уже сказали tailgunner и jtootf.

По делу всё уже сказали tailgunner и jtootf.

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

ппц уже шесть страниц. Новая традиция на ЛОРе - ежемесячный срач о геттерах-сеттерах?
http://www.linux.org.ru/forum/development/4464779/

> Новая традиция на ЛОРе - ежемесячный срач о геттерах-сеттерах?

Вечер выходного дня - хочется поговорить о простых и вечных истинах %)

эдак и поговорить не очем

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

Веско, аргументированно. Вот тебе такой же ответ: нет, не начну.

Неправильный контраргумент. Правильный вот такой: «В рантайме!» =)

О самолетах же http://www.linux.org.ru/forum/talks/4704000/page1#comment-4711699