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 следуя парадигме вышеуказанных авторов без геттеров?

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

о явном разделении интерфейса и реализации

Пользователь видит на экране интерфейс программы, реализация находится внутри программы. Условие инкапсуляции выполнено? Выполнено.

Опускаемся ниже. Что в программе? Ну, тоже интерфейсы и реализация. А зачем там повторение вышестоящего уровня абстракции? Я вот о чём.

deep-purple ★★★★★
()
void findByid(List<Book> listBook, String autor){
// код
}
tyamur ★★
()
Ответ на: комментарий от former_anonymous

Ищёт на складе по автору и т.д.

Ну так склад это отдельная сущность (контейнер). А поиск и т.п. тоже отдельные сущности (алгоритмы). У тебя типичный god class безотносительно всяких геттеров.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от deep-purple

Мысль твою не понял, вижу противоречие:

интерфейсы и реализация

А зачем там повторение вышестоящего уровня абстракции (читаю как «а зачем там абстракция»)

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

ТС спрашивает за отсутвие знание о полях объекта как таковых (типа объекты-данные - бесполезны). В общем и целом мысль интересная, но требует более высоких затрат на проектирование как минимум. И, скорее всего, более высокий уровень компетенции всей команды.

pon4ik ★★★★★
()

По ссылкам тяжелая форма ооп головного мозга:

I’ll say it again: an object is not a set of data elements and functions that manipulate them. An object is not a data entity. ... In true object-oriented programming, objects are living creatures, like you and me. They are living organisms, with their own behavior, properties and a life cycle. Can a living organism have a setter? Can you “set” a ball to a dog? Not really.

Странно, мне казалось таким переболели в лохматых 80-х еще. Но нет, продолжают натягивать модели реальности на компьютерные вычисления.

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

Одно. Потому синглтон

Почему одно? Может быть несколько складов. И даже если одно, почему синглтон? Никакой связи вообще.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Разумеется не должно быть геттеров (и вообще публичных методов) просто «шоб було».

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

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

Deleted
()
public String toXML() {
    return String.format(
      "<book><isbn>%s</isbn><title>%s</title></book>",
      this.isbn, this.title
    );
  }

Круто, чо. Было: два геттера возвращающих две разных строки и позволяющих нам выбирать, какие именно данные нам нужны. Стало: один геттер, возвращающий всё сразу, результат которого надо парсить xml-парсером.

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

anonymous
()

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

Поэтому геттеры должны быть.

deadplace
()

Он кстати про объекты-конфиги что думает? вот надо мне наконфигурировать систему. я ей передаю конфиг. как я без геттеров прочитаю значения?

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

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

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

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

случается приступ лени

Да, бывает такое. Тяп-ляп и в продакшен — наше всё! Но должна же душа стремиться к чему-то светлому.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от anonymous

Стало: один геттер, возвращающий всё сразу, результат которого надо парсить xml-парсером.

Это живой объект покакал, теперь можно посмотреть что у него там внутри не прибегая к скальпелю. Тру ООП.

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

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

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

ты не дочитал мыслю хения

Again, not the best implementation, but you see what I’m trying to show. Each time we need a new format, we create a new printer.

тоесть обана!

он там про Media решение привел, но, цуко, это тот же геттер, только еще и ВЫНУЖДАЕТ использовать все данные класса, а не только те, которые нужны.

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

ипть он наркоман

    /**
     * Get the lifetime in milliseconds.
     * @return Port number
     */
    public long lifetime() {
        return Long.parseLong(
            this.map.getOrDefault(
                "lifetime", String.valueOf(Long.MAX_VALUE)
            )
        );
    }

Ну я хз. Как по мне, так это ТЕ ЖЕ самые геттеры, только через пятку задней ноги сделаные.

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

Ну справедливости ради надо сказать, что я потыкал немного, кроме Options нигде геттеров не нашел.

Legioner ★★★★★
()

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

...поэтому геттеры должны быть /thread

next_time ★★★★★
()

Какое то ФП средствами ООП. Чё только не придумают, лишь бы не императивщина.

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

Про фанатизм - согласен. Серебрянные пули отливают понни закопанные под концом радуги.

Про сишечку - там нет прямой инструментальной поддержки ООП, однако в серьёзных API всё как-то всё равно в хэндлах представленно и интерфейсных методах а не голой попой в структурах торчит, хотя, может, дураки делали. Структуры если и используются, то в основном для упаковки аргументов.

Про вьюху - сказал А, говори и Б, там как раз обычно как минимум одна intermediate сущность представлена, а иногда и две (пресловутый model [и controller]). В случае API обычно эти штуки не раскрывают внутреннего представления или характера данных, при этом предоставляя контракт для хранения, редактирования и отображения. Если немного расширить угол обзора - то в общем и целом, 90% годного api построенны примерно по тому же принципу, как ты верно заметил без фанатизма, но собственно полей уровня author крайне мало. Просто в бизнесовом домене думать в терминах подобных абстракций сложнее, но как только дело скатывается в системщину например - там по другому проектировать и не всегда выходит.

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

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

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

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

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

Когда-то попалось видео с какой-то конференции с этим челом, сначала он сказал, что никогда не писал код за деньги а потом начал нести какую-то дичь.

Ололо, а я-то сначала подумал, что он когда-то действительно работал кодером. То есть, ни Бугаенко, ни Голуб никогда не работали кодерами? Мне нравится этот их принцип: «не умеешь писать код - учишь других, как правильно его писать».

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

Хоспади, да ты спроси сам объект этот ли автор у него

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

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

А я тебя заставляю? Это Егорушка набрасывает, а вы ведетесь.

Deleted
()

Егора Бугаенко https://www.yegor256.com/2016/04/05/printers-instead-of-getters.html

Нигде в тексте не раскрываеться почему геттеры - зло.

P.S. Автор сего опуса - известный пациент с длинным набором диагнозов с отягчающими. Я бы не рекомендовал принимать на веру его утверждения без веских аргументов. Да и время тратить на его опусы тоже.

trex6 ★★★★★
()

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

Ключевое слово - внутренние.

Если публичный интерфейс предполагает существование типа автор, для которого определено равенство, типа книга, значение которого можно отобразить в значение типа автор, типа книжный магазин, отображения значения книжный магазин и автор в можество значений книга такой, что для любого элемента этого множества отображение в автор даёт значение, равное исходному[1], то ок, почему нет?

Вообще, статью товарища Бугаенко не читал и читать не собираюсь, а в исходной статье (15-тилетней давности, кстати) автор замечает

My point is that you should not program blindly

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

[1] псевдокодом можно было бы записать как-то так:

BookStore, Book, Author : Type
author : ∀ (b : Book) → Author
searchByAuthor : ∀ (s : BookStore, a : Author) → (books : Set Book, ∀ (b : Book, b ∈ books) → author b = a)
Laz ★★★★★
()
Ответ на: комментарий от Laz

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

Жава-кретинам это надо для dependency inversion через рефлексию в рантайме.

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

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

Да, да, да. Да. Проблема заключается в том, что мой дом стал публичным, и заполнился программистами легкого поведения, именующими себя «enterprise developer». Но давайте посмотрим правде в глаза - кодинг для этого и был нужен, нет в нем никакого творчества и быть не должно, а жава-кретин - это манна небесная, которая есть твой завтрак, обед, и ужин.

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

Да, да, да. Да. Проблема заключается в том, что мой дом стал публичным, и заполнился программистами легкого поведения, именующими себя «enterprise developer». Но давайте посмотрим правде в глаза - кодинг для этого и был нужен, нет в нем никакого творчества и быть не должно, а жава-кретин - это манна небесная, которая есть твой завтрак, обед, и ужин.

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

anonymous
()

А что дальше?

Дальше — субъектное программирование. Когда экземпляр объекта знает, что делать со своими инкапсулированными и/или переданными данными при своём вызове.

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

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

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

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

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

you should not program blindly

А вообще, удивительно, что такое обсуждается. Проблема из начала 2000-х, сейчас «enterprise developer» не актуально, вместо них «frontend developer» со своими приколами.

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

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

you should not program blindly

Понимаешь, это совет уровня «вы должны ходить с открытыми глазами». На мой взгляд более действенным был бы совет «вскрой вены» или «вздернись на ближайшем тополе/осине/etc». По моим наблюдениям, человек, который в 15-20 лет не способен принимать решения, не будет способен их принимать уже до гроба - это неизлечимый экземпляр, которому нужна будет собака-поводырь до гроба. Голуб, в какой-то степени, претендует на роль этого поводыря, который будет говорить «пальцы в рот не суй... Не бегай по оридору... Новый человек зашел - поздоровайся... Сидишь в офисе, как сыч - пошел бы, погулял».

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

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

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

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

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

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

Мой ответ не был в контексте какого-то года или технологии, он был про «you should not program blindly». У меня всю жизнь проблема: я не могу делать непонятно что и не пытаться разобраться, как оно устроено и зачем я это что-то делаю. Если Голуб всерьез пытается этих людей исправить, да еще и в контексте жавы - для меня это значит что угодно, кроме «пацаны, расходимся, нас обманули». Я бы сказал, что скорее это «пацаны, у вас почти получилось, давайте еще один подход».

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

Consequently, you act irresponsibly when you adopt any programming practice simply because «that's the way you're supposed to do things.» Many failed Enterprise JavaBeans (EJB) projects prove this principle. EJB-based technology is great technology when used appropriately, but can literally bring down a company if used inappropriately.

Нет, это не жава - званый ужин на помойке, это не вы - бездари, которые никогда не смогут научиться хорошо писать код - это просто «you act irresponsibly when you adopt any programming practice».

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

Мягко говоря не все толковые люди повелись на этот рассказ:
https://web.archive.org/web/20190322230757/http://coding.derkeiler.com/Archiv...

So I went to Google in 2000 with this really impressive resume that I had built using Lisp, and when I got there they said, «Glad you're here, we want you to write Java code.» Thing is, I had never really had to learn Java, so I wasn't very good at it. On top of that, knowing Lisp made me all too keenly aware of Java's shortcomings, and I had a very hard time not being angry at how stupid it was that I was being forced to use it.

http://www.loper-os.org/?p=69

To my mind, the hallmark of the interchangeable component model of software engineers is Java. Without going into too many details, I'll just say that having programmed in Lisp the shortcomings of Java are glaringly obvious, and programming in Java means a life of continual and unremitting pain. So I vowed I would never be a Java programmer, which pretty much shut me out of 90% of all software engineering jobs in the late 90's. This was OK since I was managing to put together a reasonably successful career as a researcher. But after Remote Agent I found myself more and more frustrated, and the opportunity to work at Google just happened to coincide with a local frustration maximum.
One of the reasons I decided to go work for Google was that they were not using Java. So of course you can guess what my first assignment was: lead the inaugural Java development at the company, what eventually became Google AdWords. Thank God I had a junior engineer working for me who actually knew something about Java and didn't mind it so much. In the ancient tradition of senior-junior relationships, he did all the work, and I took all the credit. (Well, not quite — I did write the billing system, including a pretty wizzy security system that keeps the credit card numbers secure even against dishonest employees. But Jeremy wrote the Lion's share of AdWords version 1.)
I did try to introduce Lisp to Google. Having had some experience selling Lisp at JPL I got all my ducks in a row, had a cool demo going, showed it to all the other members of the ads team, and had them all convinced that this was a good idea. The only thing left was to get approval from the VP of engineering. The conversation went something like this:
Me: I'd like to talk to you about something...
Him: Let me guess - you want to use Smalltalk.
Me: Er, no...
Him: Lisp?
Me: Right.
Him: No way.

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

byko3y ★★★★
()

Подход Егорова отлично подходит когда приложение маленькое или написано на php. Зачем мне его JSON/XML, когда я прокидываю C++ объекты в колбеки какого-нибудь OpenSSL совершенно непонятно. А уж как подменить котекст для sni без геттеров вообще непонятно, ибо там такие дебри. Это касается многих библиотек, которые невозможно переписать на коленке за пару дней. Больше похоже на размышления человека, который никогда за пределы web приложений не заглядывал.

xpahos ★★★★★
()

Может ли кто-то детально обосновать нужны геттеры и сеттеры или нет.
Не знаю даже что и ответить.

ИМХНО рекомендация Егора Бугаенко похожа на - «Забудьте классы. Используйте struct. Остальное от лукавого».

anonymous
()

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

PS: Такие «программисты» похожи на Чеховского доктора.

anonymous
()

Ответ на вопрос «Что дальше?» прост.
Лучше такому «программисту» дать «кувалду в руки» /больше толку будет/.

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