Структура vs класс

Это да, кстати... Программирование - опасное дело! В программах иногда случаются ошибки! :D

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

Нужно быть клиническим идиотом, чтобы менять лёгкий метод на тяжёлый без пересмотра кода.

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

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

> Для объектов, для использования в шаблонах, требуется возвращать название страны.

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

Поэтому я и сказал, что задача специально сделана для демонстрации необходимости геттера.

нет. Выбор между полем и геттером лежит на программисте.

> учитывая, что свою позицию я изложил ровно полтреда назад

Лукавишь. Твоя позиция была изложена в третьем комменте этого треда:

никакой полезной абстракции геттеры не предоставляют

jtootf (*) (21.01.2010 16:10:52)

По части продолжения нашей дисскуссии, я согласен. Она вроде как закончена. Во всяком случае, лично я не вижу, _что_ продолжать.

P.S. Да, я её тоже вел исключительно из человеколюбия и желания потрындеть. )))

Лукавишь

вот зануда, ну. полтреда назад было дано развёрнутое изложение

По части продолжения нашей дисскуссии, я согласен. Она вроде как закончена

и потому давайте все дружно писать хороший код, а плохого кода не писать вовсе. и будет всем счастье :)

Поэтому я и сказал, что задача специально сделана для демонстрации необходимости геттера.

нет.

Да

[толсто]А хороший код - это с геттерами, исключениями, snake_case, отступами в два пробела и комментариями на английском[/толсто]

> [толсто]А хороший код - это без геттеров, с исключениями, snake_case, отступами в 1 таб и комментариями на языке команды разработчиков[/толсто]

fxd

Опять голый троллинг. Ну, как знаешь...

толсто

и на Common Lisp

>>> Поэтому я и сказал, что задача специально сделана для демонстрации необходимости геттера.

нет.

Да

MVC-подход подразумевает разделение кода и визуализации. При чём в общем случае кодом и визуализацией занимаются разные люди. Это уже автоматически подразумевает унификацию интерфейсов и сокрытие структуры объекта.

Если такая формулировка для тебя означает «задача сформулирована так, что требует наличия геттеров» - то и славненько. В очередной раз повторюсь, что я не за то, чтобы геттеры были всюду. Я против утверждения о том, что геттеры не нужны вообще.

> Если такая формулировка для тебя означает «задача сформулирована так, что требует наличия геттеров»

Нет. Вот это:

предлагаешь делать сейчас прямое обращение к public-полю класса, а завтра переписать всё на использование метода? А если объектов в шаблон подаётся более одного вида и часть может возвращать строку как есть, а часть - генерировать?

означает «задача сформулирована так...»

>Если твой шаблонизатор требует от объекта реализации конкретного интерфейса

Это не мой шаблонизатор, это, как бы, правило хорошего тона в отрасли. Без которой год считается говном :)

то и выхода какбэ нет

Ну и славненько. Значит, глобальный тезис «геттеры не нужны» уже опровергнут.

>означает «задача сформулирована так...»

Просто задача показывает типовую ситуацию в любом развивающимся со временем проекте.

...

И, возвращаясь к исходной посылке, с которой начался спор, похоже, разработчики Qt тоже уже усвоили этот опыт.

> Значит, глобальный тезис «геттеры не нужны» уже опровергнут.

А его никто и не выдвигал. Геттеры, которые сделаны «про запас», на всякий случай - не нужны. И есть мнение, что это подавляющее большинство геттеров.

> Опять голый троллинг. Ну, как знаешь...

Да я уже понял, что с вебостатистикой я угадал, не расстраивайся так. Мог бы и не напрягаться, сказал бы, что без геттеров/сеттеров не жить, потому что иначе их в Qtшные проперти не засунешь — оставался бы заодно и в рамках указанных языков. А, главное, твои примерчики ничем не лучше указания на требования Qt.

>А его никто и не выдвигал.

Здрасьте. Всё начало темы было в этом:
- http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4464788
- http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4464792

и т.д.

Геттеры, которые сделаны «про запас», на всякий случай - не нужны.

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

>Да я уже понял, что с вебостатистикой я угадал

Нет, не угадал. Вообще, в этой темы ты, сорри за тавтологию, совсем не в теме.

>>А его никто и не выдвигал.

Здрасьте. Всё начало темы было в этом:

- http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4464788

- http://www.linux.org.ru/jump-message.jsp?msgid=4464779&cid=4464792

Там по контексту ясно, что речь идет об избыточных геттерах:

класс с доступом к переменным через функции (set, get)

>Там по контексту ясно, что речь идет об избыточных геттерах

Мне не ясно. Когда я вижу высказывания, типа «никакой полезной абстракции геттеры не предоставляют», то я понимаю это толко как то, что геттеры не нужны :)

> Нет, не угадал

Да-да-да, с одной стороны у нас MMORPG, которая, судя по упоминанию дохлых клиентских тачек, требует клиента, с другой стороны веб, с той же стороны требование сделать быстро прямо сегодня, чтобы завтра слегка переделать. Конечно, это не вебостатистика, а основополагающая часть движка. 8))

Даже если я ошибся, это не отменяет остальной части комментария. Твои крайне узкие условия ничем не лучше QProperty.

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

интересный наивно-радикальный ООП (или это стиль хаскеля?)

минимальные воспоминания о Кодде и нормализации подсказали бы вопрос: а что, если функция функционально зависит от одного поля, а не от всего АТД?

допустим у нас есть user-а в разных городах, которые могут друг другу продавать всякую фигню

вариант 1: p = postal_delivery_price(user1, user2)

вариант 2: p = postal_delivery_price(user1.get_town(), user2.get_town())

в варианте 1 postal_delivery_price необходимо сделать приватной для класса User; в реальном проекте таких функций наберется немеряно (вспоминаем о популярности реляционных СУБД)

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

А разве при реализации абстракции нельзя использовать ее собственный интерфейс? Например, размер контейнера — это интерфейс или деталь реализации?

интересный наивно-радикальный ООП (или это стиль хаскеля?)

вообще-то это очевидный факт. не особо зависящий от парадигмы

функция функционально зависит от одного поля, а не от всего АТД?

и что?

в варианте 1 postal_delivery_price необходимо сделать приватной для класса User

а в варианте 2? и какое это вообще имеет отношение к обсуждаемой теме?

А разве при реализации абстракции нельзя использовать ее собственный интерфейс?

не понял. что имеется в виду?

размер контейнера — это интерфейс или деталь реализации?

интерфейс

Например, размер контейнера — это интерфейс или деталь реализации?

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

интересный наивно-радикальный ООП

http://martinfowler.com/bliki/GetterEradicator.html

http://typicalprogrammer.com/?p=23

этот интересный наивно-радикальный ООП, внезапно, является доминирующим подходом в объектном проектировании. тебя это не смущает, нет? вбей в своём любимом поисковике «getters encapsulation» и оцени количество критических статей. Фаулера, Голуба, Мейерса. наивных и радикальных

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

Да уже разобрались.

>двух языков, которые многие считают недобыдлоязыками

Это ты про Си++ или про Java? :)

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

Я же так и написал — обадва. Есть еще примеры?

>Есть еще примеры?

В других популярных языках всё решается проще на уровне синтаксиса. И поэтому сам вопрос не возникает.

>Я же так и написал — обадва. Есть еще примеры?
В тех что есть свойства, таковыми уже не считаются?

Вообще, само использование getX чисто по Фрейду как бы намекает, что в объекте уже как бы есть X и мы как бы можем его get.

само использование getX чисто по Фрейду как бы намекает, что в объекте уже как бы есть X и мы как бы можем его get

проектирование с точки зрения психоанализа - это интересно :)

>Вообще, само использование getX

Кстати, в тех проектах, где я задаю стиль, я отказался от использования префикса «get». Он подразумевается по умолчанию и эргономичность выражений, типа getInstance()->getWorlds()->getObject(id)->getCoords()->getX() сильно повышается :)

А в редких случаях, когда нужно отличить существительное от глагола использую префиксы do или on. Типа, do_job() (а, да, ещё предпочитаю snake_style :) - это ближе к естественному языку)

Вот такую профанацию идеи аксессоров как раз и называют геттеранл, именно она вызывает когнитивный диссонанс и отторжение у вменяемых программистов.

И вся эта ересь ползет из Явы, которая, в отличие от C++, не исповедует принципов суворого проектирования.

И кстати, да, хороший тест. Ведь в примере с getCountry наверняка не было симметричного setCountry, а это значит, что достаточно было обойтись country, если этого явно требовал спроектированный интерфейс.

>Ведь в примере с getCountry наверняка не было симметричного setCountry

Обязательно был. Как же без него данные-то вводить? :)

Единственное оправданное использование я видел только в Эйфеле, где поля класса синтаксически неотличимы от вызова функций без аргументов, а прямое присваивание полям класса, в отличие от Паскаля, запрещено в принципе для защиты абстракции.

Присваиванием, вестимо. Но мы это уже обсудили в разделе «свойства».

>Присваиванием, вестимо.

Даже если перед сохранением требуется обрабатывать результат. Или, там, проверять на корректность?

Кстати, если у простого агрегатора данных внезапно появился бэкенд в БД, то может лучше было бы изменить процедуру инициализации объекта и добавить процедуру сохранения с явной подержкой транзакционной целостности.

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

Да, свойства решают проблему, но там всплывает проблема автомагического поведения, из-за которой многим так не нравится C++.