LINUX.ORG.RU

Геттеры и сеттеры - зло. А что дальше?

 , , , ,


1

4

Читаю мысли Егора Бугаенко https://www.yegor256.com/2016/04/05/printers-instead-of-getters.html о том что геттеры - зло. Что-то похоже высказывал Аллен Голуб: https://www.javaworld.com/article/2073723/why-getter-and-setter-methods-are-e... .

Краткая мысль: объект не должен раздавать свои внутренние данные налево-направо. Поэтому и геттеров не должно быть.

Но вот что не даёт покоя. Как реализовать при этом подходе простейший use-case:

Есть книжный магазин BookStore. Требуется узнать какие в нём есть книги автора по его фамилии.

«Неправильный» и простейший поход, который напишет 9 из 10 разработчиков (язык неважен, хоть со стримами в java, всё одно в коде буду геттеры):

class BookStore
{
    List<Book> searchByAuthor(String author)
    {
        List<Book> found;

        for (int i = 0; i < this.books.length; i++) {
            // EVIL
            if (this.books[i].getAuthor() == author) {
                found.append(this.books[i]);
            }
        }

        return found;
    }
};


Не пойму как реализовать этот use-case следуя парадигме вышеуказанных авторов без геттеров?

Ответ на: комментарий от anonymous

Вот в видео человек на «своем месте», поэтому ему - РЕСПЕКТ.

anonymous
()
Ответ на: комментарий от Virtuos86

Кто-то где-то пукнул — давайте обсуждать. Обожаю такие треды.

Давай смотреть правде в глаза: таким пердежом завалены книжные полоки, статьи в бложиках, и учебные курсы. Люди, которые никогда не получали деньги за написание кода, учат других, как эти деньги нужно зарабатывать лучше. Люди, которые никогда не писали больших проектов, учат других, как строить архитектуру этих самых больших проектов. И индустрия рада этому, потому что, на самом деле, индустрии не нужен программист разумный - ей нужен программист послушный, который меньше думает и больше пишет.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Ближайшая - эрланг

Ближайший конкурент жавы - инферно, но, к сожалению, ботаники из bell labs не получили поддержки от бигбоссов at&t и занимались ей в свободное время, а sun поверила гослингу, дала ему бабла и запустила заодно рекламную кампанию «write once, run everywhere», что в то время было весьма актуально.

не все толковые люди повелись на этот рассказ

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

Laz ★★★★★
()
Последнее исправление: Laz (всего исправлений: 1)

Никак не надо его реализовывать иначе. Спокойно используй геттер. И спокойнее относись к таким статьям. Паттерны это не истина в последней инстанции и не статьи УК.

Слышал выражение «правила для дураков»? Многие думают что это вот такое глупое высказывание, которым люди нарушающие правила пытаются оправдываться. Другие думают что это высказывание означает что только дураки следуют правилам, я буду делать как хочу. Это все не правильно. Смысл выражения в том, что умный человек знает как поступать правильно без всяких правил, а дураку нужно правило, просто потому что без него он наломает дров.

Тут тоже самое - тебе дают правила написания хорошего кода, на тот случай если ты дурак или новичек, чтобы ты не написал говно. Эти правила нужны «не для написания хорошего кода», а «для не написания плохого кода». Если ты хорошо представляешь что ты делаешь и для чего делаешь. Можешь обосновать необходимость именно такого подхода - ничего плохого в этом нет. Хоть из одних GOTO напиши свою программу - Дейкстра одобрит.

Suntechnic ★★★★★
()
Ответ на: комментарий от Laz

Ближайший конкурент жавы - инферно, но, к сожалению, ботаники из bell labs не получили поддержки от бигбоссов at&t и занимались ей в свободное время, а sun поверила гослингу, дала ему бабла и запустила заодного рекламную кампанию «write once, run everywhere», что в то время было весьма актуально.

Да, инферно тоже хороша. Но давай начнем вот с чего: зачем бигбоссам AT&T нужна инферна? Сан продавливала идею жавы из каждого утюга и в каждый утюг, чтобы проадвать лицензии. А чтобы такой плохой инструмент (особенно до HotSpot) продавить на рынок - это оч много ресурсов нужно ввалить. Где сейчас Сан, и где - AT&T? Вот пришел гугл - он-то и доработал идею Limbo до Go, на который нынче некоторые так яростно маструбируют.

Я имел в виду не рандомных клоунов из интернета, обиженных на мир за недооценку их навыков размахивать скобками

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

парней вроде гая стила

Гай Стил не пишет на жаве, он только составляет спецификации. Иначе бы точно так же ныл. Может и сейчас ноет, но скрытно, потому что работает в оракле. Обиженные кодеры из гугла ведь тоже продолжают работать. Работать и ныть, ныть и работать - им просто не запрещают ныть публично.

джерри сассмана

Сасман никогда не писал на жаве. Он со схемы на питон перешел так-то.

фила вадлера

Вадлер не писал на жаве. Вадлер - поехавший математик, и потому фанат хаскеля. Его просто однажды пригласили поучаствовать в создании обобщений в жаве (List, Collection, Map).

эрика мейера

Он вообще тут при чем?

byko3y ★★★★
()

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

rumgot ★★★★★
()

book.HasAuthor(author) же.

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

Ты просишь у объекта книга автора, но ты просишь без уважения. Тебе не понять автора статьи, для тебя книга это всего лишь набор данных, а на самом деле это объект, у котого есть поведение. Мне даже кажется, что можно развить идеи автора дальше. Если слишком часто вызывать геттер у объекта, то он должен обижаться и кидать Exception.

nguseff
()
Ответ на: комментарий от rumgot

Это просто предложение взглянуть на проектирование под другим углом, задуматься

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Знаешь, карандашом можно чесать спину и совать его в попу. Я не уверен, что я буду делать одно или второе - стоит ли мне заранее реализовывать методы Pencil.scratchBack() и Pencil.stickIntoAss()

Самонаводящийся карандаш с дистанционным управлением? Главное не забыть параметр передать, а то еще залетит в this.ass.

bread
()
Ответ на: комментарий от nguseff

Мне даже кажется, что можно развить идеи автора дальше.

С тем, что гетты нужны только тогда, когда можешь объяснить зачем он «здесь уместен» - согласен.
Но Бугаенко вроде настаивает, что геттеры и сеттеры вообще не нужны?

anonymous
()
Ответ на: комментарий от anonymous

Но Бугаенко вроде настаивает, что геттеры и сеттеры вообще не нужны?

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

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

nguseff
()
Ответ на: комментарий от nguseff

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

Я тебе даже могу пояснить, как такое происходит. Но прежде всего выясним, что происходит. А происходит то, что ведущий идеолог завоевывания друзия и влияния на людей умирает в одиночестве; «передовые» школьные педагоги - полнейшие неудачники, а педагог-автор бестселлера отдала своего сына в детдом; люди с проблемами психики становятся психиатрами. Да-да, вспоминается знаменитый фрагмент фильма: https://www.youtube.com/watch?v=ZDRsWcSCAYw

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

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

Меня вот анон упрекал в том, что меня 5 лет не было на ЛОР-е. Вот, я пришел, принес свой опыт. Вы счастливы? Сомневаюсь. Но у меня он есть, а у егорки или голуба опыта писания программ нет вообще.

byko3y ★★★★
()
Ответ на: комментарий от rumgot

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

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

iZEN ★★★★★
()
Ответ на: комментарий от byko3y

Вот, я пришел, принес свой опыт. Вы счастливы? Сомневаюсь. Но у меня он есть, а у егорки или голуба опыта писания программ нет вообще.

Мне интересно знать ваше мнение.
«писания» или «написания» /шутка/?

anonymous
()
Ответ на: комментарий от anonymous

Но Бугаенко вроде настаивает, что геттеры и сеттеры вообще не нужны?

Мало того — он сам пишет в стиле, где не используются геттеры и сеттеры. А значит они по-сути не нужны.

(Геттеры и сеттеры — это способ безопасно сунуть объекту в его перечень параметров состояния какую-то муйню, от которой его не вырвет. Это далеко не всегда получается. Люди тратят на выяснение степени этой безопасности кучу своего и чужого времени вместо того, чтобы написать простой и понятный код в одном или двух функциональных методах, для чего, собственно, предназначен объект.)

iZEN ★★★★★
()
Ответ на: комментарий от byko3y

Вся Java построена в стиле структур данных с геттерами и сеттерами. Dependency Injection только усугубило ситуацию и затормозило выкидывание устаревших концепций на помойку истории.

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

Можно хоть какие-нибудь практические аргументы?

Почему DTO (объект, задача которого передавать данные между слоями приложения) это плохо? Чем лучше код, где объект сам себя сохраняет в базу данных, сам себя сериализует и т.д.? Только без объяснений в стиле «ты не уважаешь объект», «ООП подменили» и прочей субъективщины.

nguseff
()
Ответ на: комментарий от byko3y

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

ну как бе https://github.com/yegor256

5,559 contributions in the last year
6,939 contributions in 2018
6,437 contributions in 2017

former_anonymous ★★★
() автор топика
Ответ на: комментарий от anonymous

Как хорошо ребята, что вы все есть!
Бывает правда иногда и трудновато ...

anonymous
()
Ответ на: комментарий от former_anonymous

Пусть продвигает свои идеи.
Мы же не инквизиция /да и идей у нас по десять, на каждую его/.

anonymous
()
Ответ на: комментарий от byko3y

И какой вывод мы должны сделать из твоего сообщения? Что ты читаешь книги?

Что геттеры ломают, «пирамиды наследования». Зачем эти пирамиды строить там, правда, не сказано.

nguseff
()
Ответ на: комментарий от iZEN

Вся Java построена в стиле структур данных с геттерами и сеттерами. Dependency Injection только усугубило ситуацию и затормозило выкидывание устаревших концепций на помойку истории.

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

Если говорить про связывание классов интерфейсами, то get/set неизбежно, поскольку интерфейс не позволяет читать-писать поле - никуда от этого убежать не получится. А какая разница, передаешь ли ты через интерфейс правила работы с полем или метод? Ты просто передаешь то, что тебе нужно передавать - вот и все дела.

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

byko3y ★★★★
()
Ответ на: комментарий от former_anonymous

ну как бе https://github.com/yegor256
5,559 contributions in the last year
6,939 contributions in 2018
6,437 contributions in 2017

А теперь посмотри, что в них. Один коммит - одна-две-три строчки:
https://github.com/zold-io/zold/commit/127b9745c0ad8b5662c5e93b7d896cae9d1e854d
https://github.com/zold-io/zold/commit/243fe4e98efb4355b7f9e92fba66d76405f7afdb
https://github.com/zold-io/zold/commit/82cb140aa806f9ada1ec9afeacc009d1449faf40
https://github.com/zold-io/zold/commit/765eb6e1fe302f8050e06971192b05205e31669d
Все проекты - детский сад, самый большой модуль в zold-io парсит аргументы командной строки. Но да, действительно, Егорка что-то пишет. По крайней мере, делает вид.

byko3y ★★★★
()
Ответ на: комментарий от nguseff

Можно хоть какие-нибудь практические аргументы?

Можно посмотреть на библотечные классы Java, особенно оставшиеся «для совместимости» — все аргументы налицо.

iZEN ★★★★★
()
Ответ на: комментарий от nguseff

Почему DTO (объект, задача которого передавать данные между слоями приложения) это плохо? Чем лучше код, где объект сам себя сохраняет в базу данных, сам себя сериализует и т.д.?

DTO — это антипаттерн ООП.

«В Enterprise JavaBeans DTO используется для сериализации.

Entity beans представляют объекты, находящиеся в постоянном хранилище, например, в базе данных. С одной стороны, это очень удобно, так как программа-клиент не должна заботиться о подсоединении к базе данных напрямую. С другой стороны, каждое изменение в entity bean может вызывать методы удалённого доступа, что увеличивает нагрузку на сеть и снижает скорость работы программы. Sun Java Center порекомендовал для решения этой проблемы изолировать все данные в отдельный объект и передавать этот объект в entity bean одним методом.

В версии EJB 3.0 модель записи данных была изменена, эта проблема была разрешена и нужда в DTO отпала.»

© Wikipedia

iZEN ★★★★★
()
Ответ на: комментарий от byko3y

Я не пропагандирую криптопись, вроде лиспа

Код на лиспе простой как тапок. Криптопись, совсем упоролись.

Hertz ★★★★★
()
Ответ на: комментарий от iZEN

DTO — это антипаттерн ООП.

Строка - это типичный DTO. И что, кто-то возмущается?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Один коммит - одна-две-три строчки

пусть так, пусть получится ~10'000 строк в год. Далековато от понятия академического теоретика.

former_anonymous ★★★
() автор топика
Ответ на: комментарий от byko3y

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

Самое интересное, что даже на джаве или c# эти иерархии практически никто не пишет. Код в большинстве проектов выстроен по законам функциональной (!) декомпозиции: объекты с данными и stateless сервисы с интерфейсами, нет там никаких иерархий. Java просто удобна, как интструмент со всякими фреймворками. SOLID и GRASP позволяют писать более менее предсказуемый и поддерживаемый код.

Но тут откуда ни возьмись появляются адепты «правильного ООП», которые начинают рассказывать, что никто ничего не понимает, «ООП подменили» и т.д., и надо срочно возвращаться к истокам.

nguseff
()
Ответ на: комментарий от byko3y

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

byko3y ★★★★
()
Ответ на: комментарий от former_anonymous

пусть так, пусть получится ~10'000 строк в год. Далековато от понятия академического теоретика.

Это есть предположить, что каждая строка - это новая фича. А если предположить, что Егорка просто таскает строчки взад-вперед, то можно 10 тысяч строк правок в год сделать на проекте в 100 строк.

byko3y ★★★★
()
Ответ на: комментарий от iZEN

DTO — это антипаттерн ООП

бездоказательное утверждение.

С другой стороны, каждое изменение в entity bean может вызывать методы удалённого доступа

какое отношение это имеет к DTO?

nguseff
()

плохо читал? Это полностью корректный пример.

class BookStore
{
    List<Book> searchByAuthor(String author)
    {
        List<Book> found;

        for (int i = 0; i < this.books.length; i++) {
            // EVIL
            if (this.books[i].author() == author) {
                found.append(this.books[i]);
            }
        }

        return found;
    }
};

Вообще статья - криво объяснённая иммютабельность.

Например: setAuthor(author) не имеет смысла, есть книга, у них авторы не меняются, опять же название, автор, это характеристики книги, если это и меняется то скорее всего это уже новая книга => объект. глупо распространять этот концепт на всё, возьмём объект USER у него есть Name, Gender, в силу «естественных» трансформаций, таких как брак, фамилия может поменяться(с Gender сам додумай) и иметь setter для этого поля нужно, можно назвать его .rename(newName), чтоб не плакаться о setName. у нас не новый объект, а изменение текущего.

Очень просто иммуютабельным объектам set/get - зло.

ksim
()
Ответ на: комментарий от byko3y

То есть, ни Бугаенко, ни Голуб никогда не работали кодерами?

Про второго не знаю.

ya-betmen ★★★★★
()

Так уже никто не пишет.

Сейчас надо типа такого (примерный код, проверять мне лень)

public Optional<Book> findAuthor(final List<Book> list, final String name) {
    return list.stream().filter(book -> book.getAuthor().equals(name)).findAny();
}

Вывод - «автор» обыкновенный «выпендрёжник» (я не использую запрещённый правилами ЛОРа неприличный термин)

Может быть представлен в двух видах: «Джун», чье поведение может быть 
обусловлено отсутствием опыта работы в бодишопе или попыткой 
самоутвердиться, обычно с возрастом проходит. Но примерно в 50% случаев 
болезнь переходит в хроническую форму — «Ыксперт», характеризующуюся как
 недержанием IT, так и периодической потребностью раздавать всем бесплатные 
советы — начиная от дворников и сантехников, и заканчивая депутатами и 
президентами. Агрессивно реагируют на малейшую критику и ненавидят 
[невыпендрёжников - B.], считая их «не труъ» айтишниками.

(С)

А я не клоун с «Джокера».

Я - «раб галерный»(С). Я - НЕ-Ъ.

Bioreactor ★★★★★
()
Последнее исправление: Bioreactor (всего исправлений: 1)
Ответ на: комментарий от byko3y

Про таки Голуба - он реально пейсал код.

Только это было давно.

Еще в эпоху Zortech С++, ну, может быть, Borland C++ 1.0.

Когда программисты просто создавали реально полезные программы, а не «мерились мобилами»(R), что круче - Groovy или Scala.

Хотите посмотреть на любителей поучать «джунов» - запишитесь на «Джокер».

Bioreactor ★★★★★
()

Прочитал я эту хреновину. Насколько я понял там вся фишка в immutable. Т.е., блин, смысла особого нету. Хз.

anonymous
()
Ответ на: комментарий от iZEN

Мало того — он сам пишет в стиле, где не используются геттеры и сеттеры. А значит они по-сути не нужны.

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

Ну хз. Массивы есть. Циклы есть. Условные переходы есть. Функции есть. Если подумать, то и структуры есть. ЯВУ не далеко от ассемблера ушли, добавив только изоляции всякие.

anonymous
()
Ответ на: комментарий от iZEN

простой и понятный код в одном или двух функциональных методах

Поржал.

ya-betmen ★★★★★
()
Ответ на: комментарий от ksim

Например: setAuthor(author) не имеет смысла, есть книга, у них авторы не меняются, опять же название, автор

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

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Подождать коллапса и перерождения вселенной и в следующем цикле написать правильно. А вообще, я так понял, что объект просто уничтожается и создаётся новый — правильный. И всё.

anonymous
()
Ответ на: комментарий от deep-purple

курица или яйцо?

ДНК-содержащий вирус, протея, митохондрия, аппарат Гольджи — все они объеденились, чтобы являть собой животную клетку. Т.е. даже если углубляться — ответ — ни то, ни то, и, и то, и то. Вот так вот. Деды, короче.

anonymous
()
Ответ на: комментарий от anonymous

А вообще, я так понял, что объект просто уничтожается и создаётся новый — правильный. И всё.

И в чем разница, кроме ублажения бога иммутабельности?

ya-betmen ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от ya-betmen

Только ублажения бога неизменности (иммутабельности). Это всё. В кабине может быть, у макак, от этого посветлее станет. Обычным же смертным это просто yet another approach. Ну типа, что не поменяешь данные по запарке, хотя это и не реально. Даже для макаки трудновато. Может имеется ввиду работа в потоках. Иммутабельный объект не нуждается в примитивах синхронизации. Типа не стрёмно, что с соседнего потока его кто-нть изменит. Типа того, короче.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.