ООП-дичь

Выдержки из радио-беседы о концепции Егора Бугаенко, сентябрь 2016

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

Поиск максимального из 2 чисел:

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

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

Принтеры против геттеров:

Мы не хотим чтобы кто-то из нас что-то "гет". Мы хотим чтобы нас попросили куда-то "принт".

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

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

Статье, что геттеры и сеттеры (Алан Холуб) - это зло уже 10 лет. Но что поменялось?! Повсеместное использование. Куча модных прибамбасов и генераторов автоматически создающие геттеры/сеттеры.

Геттеры - нарушают инкапсуляцию. Их вообще не должно быть, также как и атрибутов, которые видны наружу. И проблема не в том что они какие то некрасивые, а в том что они разбивают объект на кусски и растаскивают его (наружу). Объект превращается просто в набор данных, которыми кто-то снаружи должен управлять. Кто-то должен сделать гет и кто то должен сделать сет.

Паттерн объект - тоже плохо (когда мы например данные о каком-то из БД берем упаковываем в объект и передаем) проблема то, что объект становится переносчиком данных, а этого не должно быть. Сам принцип ООП - сделать так чтобы данные перестали быть нам видны.

Когда - кто-то берет данные и упаковывает их в объект, передает в нужный слой, который эти данные распаковывает и дальше отрисовывает - то данные видны

А как же нам тогда работать с данными из БД? А мы с ними не должны работать. Создается объект HTML страница и этот объект сам знает как себя достать из БД и как себя нарисовать в нужном формате

Идея разбиения приложения на слои неправильно понята... и потому кошмар

active record pattern тоже никуда не годится

- ошибка разбивать данные на клиентские и сервера;

- все данные должны быть инкапсулированы;

но это джава сервер пэйдж?

рич обжект?

Объект жив.и он знает что делать. В нем все внутри. он активен. 

Но например. объект содержит инфу, которая может быть представлена в HTML, XML и JSON. Инкапсулировать это вcе три формата в одном объекте - ад. Гораздо проще, создать один объект, который выводит инфу.... в другой объект, который уже ее превращает в то, что надо

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

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

- DTO? необходимое зло - разве нет?
- Нет!

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

String: 

Этот класс - одна большая ошибка. Там десятки методов, когда должно быть не больше 3-4 штуки. Он нарушает принцип single responsibility. Нужно по другому это было все оптимизировать не пихать все методы вовнутрь одного класса.

Коллекции:

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

В чистом виде данные не присутствуют в мире. Объекты которые обладают свойствами.

Стримы:

Они ведь не гет-что-то, они "трансформируют" коллекцию.

Лямбды - это функциональное программирование: 

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

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

Джава слишком мейнстримовская:

Она постоянно все вбирает (все подряд, что нравится программистам) но почти ничего не убирает. Но мы же тащим в дом все что используем. 

Никого это не волнует, что Java код загромождается... поскольку он выполняется на локальных машинах, производительность которых стремительно растет, компилятор может что-то почистит еще... это все развращает.

Должна быть цельность языка, а Java превращается в монстра, типа C++ которого уже никто не понимает. Смешение идеологий принесет только вред. Это движение убьет язык ... впрочем может и к лучшему - освободится место для новых.

http://razbor-poletov.com/2016/09/episode-116.html