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

Приходит такой объект на границу

Ну там типа прапорщик `get_object_name` берёт этот объект целиком и извлекает из него имя. Хотя имя-то в поле. Иммутабельном поле. Т.е. даже прапор не нужен.

anonymous
()

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

O OCP[6] Принцип открытости/закрытости (The Open Closed Principle) «программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

https://en.wikipedia.org/wiki/SOLID

anonymous
()

Если, кто не хочет использовать Groovy и Scala:

https://projectlombok.org/

-----

А для тех, кто хочет изучить диалекты от Одерски и Стрэкена:

class Person() {
   var name: String = null
}

транслируется в

...
    public String name()
    {
        return name;
    }

    public void name_$eq(String x$1)
    {
        name = x$1;
    }
...
    private String name;
class Person {
   String name
}

транслируется в

...
    public String getName()
    {
        return name;
    }

    public void setName(String s)
    {
        name = s;
    }
...
    private String name;
...
Bioreactor ★★★★★
()
Ответ на: комментарий от anonymous

Вопросы по SOLID на собеседовании в 90% процентах сразу же вводит кульхацкеров в ступор.

Неофиты на ЛОРе - они у нас не читатели, а письменники.

Хотя уже геттеры-сеттеры мы тут обсуждали -

OOP и common sense (комментарий)

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

Вопросы по SOLID на собеседовании в 90% процентах сразу же вводит кульхацкеров в ступор.

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

byko3y ★★★★
()

Имеются поля к которым из-за разных причин лучше не давать прямой доступ.
Вот для них очень даже уместны get и set ...

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

Все зависит от «функциональности» полей и от задачи.
В некоторых случаях get и set выступают в роли триггеров.

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

Умничать будете на собеседовании.

А пока сублимируйте и завидуйте молча.

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

я плохой кодер на Java.

Согласен.

Зато Вы самокритичны.

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

Вопросы по SOLID на собеседовании в 90% процентах сразу же вводит кульхацкеров в ступор.

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

Знание, понимание ряда принципов и умение их эффективно применять на практике безусловно круто.

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

Вопросы по SOLID на собеседовании в 90% процентах сразу же вводит кульхацкеров в ступор.

Особенно полезно понимание, как и где это можно эффективно применять

Люди, пишущие на Java, не понимают SOLID, иначе бы они не писали на жаве. По сути, часть «OLID» значит, что наследование не нужно, поскольку «OL» лишает наследование смысла и «ID» заменяет его интерфейсами, а часть «S» значит, что на пару-тройку функций ты будешь делать отдельный класс и модуль (поскольку в жаве публичный класс = модуль).
Это примерно как взять велосипед, открутить от него одно колесо, приварить зонт - и ездить на этом. То есть, язык приводится в негодность. Я ни минуты не сомневаюсь, что эти боль и страдание являются будничным явлением для кодера на Java. И если завтра кодеру скажут, что для написания хорошего кода нужно засунуть в попу самотык - он это сделает, и будет сидеть с серьезным видом в одном офисе с такими же коллегами, не имеющими ни малейшего понимания того, зачем этот самый самотык был нужен.

byko3y ★★★★
()

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

Найти ответ на вопрос может помочь выступление Егора Бугаенко на съезде «Джиконф» в Киеве в 2016 году.

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

Найти ответ на вопрос может помочь выступление Егора Бугаенко на съезде «Джиконф» в Киеве в 2016 году.

А можно сразу ссылку на конкретное время? Мне неинтересно слушать, как Егорка 45 минут переливает из пустого в порожнее.

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

А можно сразу ссылку на конкретное время?

с 26-й по 31-ю минуту виден итог рассуждений Егора о преимуществе подхода к написанию кода с неизменными объектами против объектоизменяемого подхода.

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

с 26-й по 31-ю минуту виден итог рассуждений Егора о преимуществе подхода к написанию кода с неизменными объектами против объектоизменяемого подхода.

https://www.youtube.com/watch?v=9lbxz6VaRKc#t=29m40s
29:40

Но если вы откроете сам этот класс Email - в нем больше двух тысяч строк. То есть, понять его, поддержать его, расширить его, добавить в него новый функционал - ну, это задача просто неподъемная, это может сделать только тот, кто его писал. Потому что он огромный, потому что он - monster class, он тот самый monster object или god object - you name it.

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

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

Не будем спешить с выводами.
ИМХНО пока не могу привести доводы «за» /наверное они имеются/.
Вообще рассуждения об объектах зачастую, какие-то «однобокие».
Остроконечники говорят все объекты должны быть «белыми», тупоконечники утверждают, что все объекты должны быть «черными».

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

пока не могу привести доводы «за» /наверное они имеются/.

«За» что?

Остроконечники говорят все объекты должны быть «белыми», тупоконечники утверждают, что все объекты должны быть «черными»

Остроконечники - мудаки, тупоконечники - обмудки.

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

«За» что?

Полезности в советах Егора Бугаенко /впрочем их там аж 23/.
Хотелось бы с мнение других программистов познакомиться.

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

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

Хотелось бы с мнение разных программистов познакомиться.

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