OOP и common sense

инкапсуляция чего именно сломается, если все переменные (в твоем конкретном случае) имеют точно такой же уровень доступа, как при использовании кейворда public?

https://projectlombok.org/

хотя он и говно, но в моменты осознание бренности сущего помогает

Инкапсуляция сломается

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

то что в жабе называют паблик и делают через него, также является инкапсулированным поведением, просто объект решил, что он будет удовлетворять любые сообщения на изменения. В ООП инкапсулированно абсолютно все. Там не может быть ничего такого, что не инкапсулированно.

OOP ∉ {common sense}

/thread

It's messaging that really forces clean encapsulation. Otherwise, you can end up in getter/setter hell, where everybody still knows everything about everything, even though all data is private.

https://news.ycombinator.com/item?id=1355977

Это величайшая из идей, которые существовали когда либо в CS. Но и самая массово непонятая, и извращенная дезигнерами недоязычков на свой лад, в меру своего понимания (точней — непонимания), идея.

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

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

Так я привык делать и пишу так уже лет 10

Блин, реально, ты серьезно? xD

Ну и я хотя бы надеюсь что, эти «вставки» у тебя генерируются автоматически, и ты не прописываешь их руками. Тогда еще можно свалить все на «лень перенастраивать». Но если ты это еще и руками пишешь, тогда это фейспалм 80-lvl...

Мало того, что куча глупого кода

Посмотри на Lombok

Не проще ли сделать эти 10 переменных public и пользоваться вот так сразу.

Плюсы геттеров-сеттеров:

1. Унификация кода. Код вида return point.getX() + rect.x; это полный отстой. А сколько-то нетривиальных геттеров у тебя будет в любом случае.

2. Можно ставить брякпоинты в геттерах и особенно в сеттерах. Нужно редко, но метко. Справедливости ради надо отметить, что брякпоинты можно ставить и на полях, но почему-то в идее такая штука жутко замедляет программу и во многих случаях делает её неюзабельной.

3. Таки рефакторинг, если реализация понадобилась, проще, чем с переменными.

4. Никто не задаёт глупых вопросов, а почему тут без геттеров-сеттеров. Меньше слов, больше дела.

Инкапсуляция сломается

А вот инкапсуляции в тупых геттерах-сеттерах ровно 0.

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

А вот это зря. Property это правильное решение твоих страданий и их завезли кажется везде, кроме Java. Поэтому, если есть возможность: Kotlin, Scala и не страдай.

Поэтому, если есть возможность: Kotlin, Scala и не страдай.

Вот, справедливости ради, дельный совет xD

Это если джава стала тебе как короткие штанишки:
Case Classes
Data Classes

То есть, тут у тебя есть типы (в т.ч. вложенные, и их коллекции) без поведения (АТД в случае Скалы), и цепочки преобразований над ними: map, flatMap, fold, match, copy. Просто, читаемо, защищено от ошибок.

1. Унификация кода. Код вида return point.getX() + rect.x; это полный отстой. А сколько-то нетривиальных геттеров у тебя будет в любом случае.

И т.д. по списку. Это все вот о замшелом ынтырпрайзе? Ведь жабу и в вебе юзают, и иногда просто реально проще тыкать все в филды, и не париться. Ну а аргументы типа bp/унификации/лишних вопросов, какие-то, уж извините, слишком специфичные.

И т.д. по списку. Это все вот о замшелом ынтырпрайзе?

Я не понимаю такого термина. Если о хорошем коде, то да.

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

Нет никакого «парева» в использовании геттеров/сеттеров. Написал поля, нажал две кнопки и все геттеры-сеттеры магическим образом появились. Или через ломбоковские аннотации.

Ну а аргументы типа bp/унификации/лишних вопросов, какие-то, уж извините, слишком специфичные.

А какие аргументы в пользу полей?

При наличии геттеров/сеттеров без причины ты и так ломаешь «инкапсуляцию». Так что забей.

А про SOLID не знаем?

Не-а?

http://stackoverflow.com/questions/1568091/why-use-getters-and-setters

А какие аргументы в пользу полей?

Вы ведь знаете, что многие объекты в жабе используются _просто для хранения_ данных. Только структура. Более ничего. И там _могут быть_ не нужны никакие бряки. Это просто коробка для хранения. В таких объектах создавать геттеры/сеттеры _избыточно_. В вашем случае, скорее всего, вы их создаете просто потому что в конторе, где вы работаете, есть определенные стилистические нормы для написания кода. Устоявшиеся традиции. Но ответьте честно, у вас не бывало такого, когда вы смотрите на примитивную коробку с простыми полями, и думаете «Зачем ей вообще аксессоры?». Я понимаю, что сейчас могут посыпаться аргументы а-ля «сейчас не нужны, завтра я добавлю туда метод раз/метод два/etc», но для этого, на минуточку, и существует этап _проектирования_.

Нет никакого «парева» в использовании геттеров/сеттеров. Написал поля, нажал две кнопки и все геттеры-сеттеры магическим образом появились. Или через ломбоковские аннотации.

Я и не спорю, и не говорю о «пареве» в контексте создания. Просто есть такое хорошее слово – избыточность. Если ваши нормы заставляют использоваться аксессоры абсолютно везде, ну значит, используйте. Но ИМХО, если на этапе проектирования, четко определено, что объект А не будет иметь никаких методов, а просто будет содержать какие-то данные, не будет никакой проблемы в приведенном вами примере кода return point.getX() + rect.x;, ибо как по мне, это уже субъективщина конкретной команды разрабов.

Я не понимаю такого термина. Если о хорошем коде, то да.

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

Я ни в ком разе не хочу сказать что аксессоры это плохо. Это уже устоявшаяся система. Я всего лишь хочу сказать что иногда простые филды можно и нужно использовать, и при правильном применении – они ну никак не усложнят вам работы.

А SOLID тут при том, что?

Сеттеры, это не только ценный мех, в них еще бывает полезная логика. Хотя меня до сих пор не покидает мысль, что класс и геттеры/сеттеры было бы удобней видеть в разных файлах.

Все это уже обсуждали

https://toster.ru/q/201643

«не переписывая весь код» == «открыто для расширения, но закрыто для изменения»

Вы только что сломали пункт 4 :(

4. Никто не задаёт глупых вопросов, а почему тут без геттеров-сеттеров. Меньше слов, больше дела.

Да, вы сломали систему. Стыдно должно быть, товарищ...

Я в своих проектах юзаю public поля и не парюсь. Не только в доменах, но и почти везде в других классах. Все равно пока ни один не выстрелил. А если что-то выстрелит и нужно будет нанять кучу макак на поддержку, то рефакторнуть обратно на геттеры/сеттеры - один день работы.

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

Совесть не разрешает.

Называть методы blablabla совесть разрешает?

Для совсем тупых объектов иногда использую public final. Но такое не все либы жуют, всякие апач бинутилсы и прочее. К тому же скрытие пропертей и дерганье свойств по типу переменной.

Так что если ломает писать геттеры-сеттеры (умеет любая ИДЕ) используй lombok.

В таких объектах создавать геттеры/сеттеры _избыточно_.

а потом хочется подебажить и становится мучительно больно :)

на минуточку, и существует этап _проектирования_.

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

1. не очень хорошо.

2. это почти никогда не работает лет хотя бы на 5 вперед.

увы и ах.

Научно это называется аутизм.

наверное еще застали время когда в жабе вообще не было пропертей

Эээ... в жабе есть проперти?

а потом хочется подебажить и становится мучительно больно :)

Филды нормально не дебажатся? Вы явно делаете что-то не так.

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

1. не очень хорошо.

снова субъективщина конкретной команды...

2. это почти никогда не работает лет хотя бы на 5 вперед.

есть такое понятие _предполагаемое время жизни проекта_. Обычно, при проектировании, это учитывается, да да! :)

увы и ах.

И даже небо, и [вырезано_по_танцпольным_соображениям] ... xD

Эээ... в жабе есть проперти?

Братишка, я тут тебе медаль принес!
http://lphoto3.ask.fm/576/339/664/-449996974-1t14m9f-b0o0a07i5fe0lfp/original...

а потом хочется подебажить и становится мучительно больно

Преждевременная оптимизация чего бы то ни было (в данном случае - будущего рефакторинга или отладки) - ну, дальше вы знаете... :)

обычно это случается гораздо чаще и раньше чем кажется.

ну или я делаю что-то не так ))

Филды нормально не дебажатся?

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

снова субъективщина конкретной команды...

погоди, почему одной?

есть такое понятие _предполагаемое время жизни проекта_. Обычно, при проектировании, это учитывается, да да! :)

самый популярный фокус: легаси. еще один популярный фокус: человек ушел, проект заброшен и воскрешен другим.

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

правда к этому моменту геттеры и сеттеры уже есть ))

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

Зачем получать стек при обращении к переменной? Поток – приватный стек, понимаю. Метод – приватный фрейм-стек _в пределах потока_, понимаю. Но... для чего... нужно получать стек _именно при обращении_ к переменной? Ну получите его до, ну получите его после. Но зачем _именно при обращении_? Просто хочется? xD Тогда вы явно делаете там что-то не так.

погоди, почему одной?

Ну знаешь, такая _большая большая_ команда, состоящая из _маленьких маленьких_ xD

самый популярный фокус: легаси. еще один популярный фокус: человек ушел, проект заброшен и воскрешен другим.

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

Суровые реалии, они такие. Придется страдать, если уж так хочется xD

этот выздоровел, выписывайте

Чтиво по теме http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-meth...

этот выздоровел, выписывайте

Аутизм не лечится. У ООП-шников все признаки на лицо:

Стереотипия — бесцельные движения (взмахи руками, вращение головы, раскачивание туловища).
Компульсивное поведение — намеренное соблюдение неких правил, например расположение объектов определенным образом.
Потребность в однообразии, сопротивление переменам
Ритуальное поведение — выполнение повседневных занятий в одном порядке и в то же время, например соблюдение неизменной диеты или ритуала облачения в одежду.
Ограниченное поведение — узкосфокусированное, при котором интерес человека или его активность, например, направлены на единственную телепрограмму или игрушку.

Но зачем

т.е. никак. отличное решение.

Суровые реалии, они такие.

:(

Accessors also end up in designs by force of habit. When procedural programmers adopt Java, they tend to start by building familiar code. Procedural languages don't have classes, but they do have the C struct (think: class without methods). It seems natural, then, to mimic a struct by building class definitions with virtually no methods and nothing but public fields. These procedural programmers read somewhere that fields should be private, however, so they make the fields private and supply public accessor methods. But they have only complicated the public access. They certainly haven't made the system object oriented.

Да я сам так делал! xD
Воды в статье многовато, но пара дельных мыслей там имеется. Процедурщина и приводит ко всем этим проблемам, типа божественных классов. Для начала, неплохо было бы прочитать «Object Thinking», чтобы начать понимать, почему с точки зрения мира объектов, такой код

...
Child child = new Child();
child.setToy(new Toy());
...

...
Child child = new Child();
child.take(new Toy());
...

т.е. никак. отличное решение.

Дак вопрос был _зачем_? Назовите конкретный случай, а я попробую найти решение xD

И что, теперь не скомпилится??!
Боже, что я наделал...

Покайся, сын мой! Откажись от жабы совсем. Пока еще не поздно спасти свою душу xD

Иногда можно ещё и так:

new Child(){{
   take(new Toy());
}}

Поздно, я уже запушил

Главное чтобы разработчик понимал, что setWeight(25) – не православный метод, и нужно _по возможности_ давать объектам права изменять свойства, исходя из реальных причин, а не просто потому что так запросил клиент. Да, это лютейший ООП головного мозга, но только в нем вся прелесть.

Пишу на java уже довольно давно и всем командам навязываю мнение, что public для pojo правильно и богоугодно. Это вообще никак не относится к инкапсуляции.

Ну оно и не логично как-то, мы ведь не можем реальному обьекту взять и изменить вес, не изменив например объём, без чёрной магии (рефлексии)

10 членов-переменных. И ничего вроде бы больше нету, так как это на самом деле тип, а не объект.

Если есть структура, есть и методы работы с ней, а значит, что ты делаешь что-то не то.

КОП (классо-ориентированное программирование), его термины, плохо подходят для такого языка. Эти идеи нужно разговаривать исключительно с помощью терминов интерфейсов и их реализаций.

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

Почему же? И для какого же тогда они подходят?

Эти идеи нужно разговаривать исключительно с помощью терминов интерфейсов и их реализаций.

ЯННП. Честно, я пытался.

Почему же? И для какого же тогда они подходят?

Для КОП, очевидно. Для нормального программирования не очень.

ЯННП. Честно, я пытался.

сорри, забываю постоянно про туповатость программистов. Объясняю: слова класс, наследование, является подтипом и может что-то ещё позволяют описать КОП. На практике же, для построения нормальных архитектур, достаточно слов «сигнатура интерфейса» и «удовлетворяет сигнатуре интерфейса» (практические примеры такого подхода см. в Хаскеле, Го, Расте и т.п.). Словарь КОП позволяет выразить эти практические потребности, но только за счёт большего числа слов. Это означает, что терминология КОП оказывается не самым лучшим практическим решением. С математической точки зрения она просто неудачна: требует больших формул и усиливает ментальную нагрузку.