Выдержки из радио-беседы о концепции Егора Бугаенко, сентябрь 2016
Лямбды - это функциональное программирование:
Лямбды - удобно но не в ооп. В ооп - нет понятия функции. Даже, если на самом деле лямбда это интерфейс - он выглядит как функция и заставляет нас думать в функциональном стиле, провоцируют применение стат.методов.
http://razbor-poletov.com/2016/09/episode-116.html
По началу точка зрения кажется странной, особенно если смотреть в отрыве от всей цепочки выводов сделанных ранее и, которые были причиной... это лишь вершина айсберга, и смотреть нужно в глубину
Поиск максимального из 2 чисел:
Сначала сравниваем 2ве переменные, делаем выбор большего и возвращаем его прямо здесь и сейчас. Просто. Но это императивный подход, процедурный.... мы даем инструкцию и ждем результат.
Сначала сравниваем 2ве переменные, делаем выбор большего и возвращаем его прямо здесь и сейчас. Просто. Но это императивный подход, процедурный.... мы даем инструкцию и ждем результат.
В ООП же мы создаем новый объект, который обладает свойствами наибольшего значения из этих 2х, т.е. само вычисление - мы инкапсулируем внутрь объекта. Вообще все д.б. инкапсулировано.
Принтеры против геттеров:
Мы не хотим чтобы кто-то из нас что-то "гет". Мы хотим чтобы нас попросили куда-то "принт".
Весь джава мир живет геттерами... но это нужно менять. Геттеры - категорическое зло - нельзя использовать иначе это не ооп.
Я не приемлю другой подход и не соглашусь на полумеры... поскольку когда у людей есть выбор - им лень/трудно/не хочется и еще множество причин не делать так как надо.
Статье, что геттеры и сеттеры (Алан Холуб) - это зло уже 10 лет. Но что поменялось?! Повсеместное использование. Куча модных прибамбасов и генераторов автоматически создающие геттеры/сеттеры.
Геттеры - нарушают инкапсуляцию. Их вообще не должно быть, также как и атрибутов, которые видны наружу. И проблема не в том что они какие то некрасивые, а в том что они разбивают объект на кусски и растаскивают его (наружу). Объект превращается просто в набор данных, которыми кто-то снаружи должен управлять. Кто-то должен сделать гет и кто то должен сделать сет.
Паттерн объект - тоже плохо (когда мы например данные о каком-то из БД берем упаковываем в объект и передаем) проблема то, что объект становится переносчиком данных, а этого не должно быть. Сам принцип ООП - сделать так чтобы данные перестали быть нам видны.
Когда - кто-то берет данные и упаковывает их в объект, передает в нужный слой, который эти данные распаковывает и дальше отрисовывает - то данные видны
А как же нам тогда работать с данными из БД? А мы с ними не должны работать. Создается объект HTML страница и этот объект сам знает как себя достать из БД и как себя нарисовать в нужном формате
Идея разбиения приложения на слои неправильно понята... и потому кошмар
active record pattern тоже никуда не годится
- ошибка разбивать данные на клиентские и сервера;
- все данные должны быть инкапсулированы;
но это джава сервер пэйдж?
рич обжект?
Объект жив.и он знает что делать. В нем все внутри. он активен.
Но например. объект содержит инфу, которая может быть представлена в HTML, XML и JSON. Инкапсулировать это вcе три формата в одном объекте - ад. Гораздо проще, создать один объект, который выводит инфу.... в другой объект, который уже ее превращает в то, что надо
Когда в жизни ты что-то хочешь получить от меня, какую то информацию, ты просишь написать мне это, а геттер - это когда ты залезаешь ко мне в мозг и выковыриваешь эти данные из головы. Это не правильно.
Нельзя вытягивать информацию, объект сам распоряжается ею и принимает решение направить туда или туда. А как только возникает геттер - то именно он становится активным... а объект лишь пассивным хранилищем.
- DTO? необходимое зло - разве нет?
- Нет!
- DTO? необходимое зло - разве нет?
- Нет!
Потому что так, конечно, проще - взять и вывалить данные. Но так нарушается принцип ООП - сокрытия данных. Информация должна быть скрыта за границами объекта и только объект решает как выдавать ее и когда.
String:
Этот класс - одна большая ошибка. Там десятки методов, когда должно быть не больше 3-4 штуки. Он нарушает принцип single responsibility. Нужно по другому это было все оптимизировать не пихать все методы вовнутрь одного класса.
Коллекции:
Да, это данные, но воспринимать их нужно (организовывать) как объекты. В идеале коллекции не позволяют из себя что-то доставать... они сами могут вывести что-то на печать (список пользователей, например)
В чистом виде данные не присутствуют в мире. Объекты которые обладают свойствами.
В чистом виде данные не присутствуют в мире. Объекты которые обладают свойствами.
Стримы:
Они ведь не гет-что-то, они "трансформируют" коллекцию.
Они ведь не гет-что-то, они "трансформируют" коллекцию.
Лямбды - это функциональное программирование:
Лямбды - удобно но не в ооп. В ооп - нет понятия функции. Даже, если на самом деле лямбда это интерфейс - он выглядит как функция и заставляет нас думать в функциональном стиле, провоцируют применение стат.методов.
Лямбды это удобное зло - нужны анонимные классы, даже если это довольно громоздко. Я использую лямбду... т.к. код становится короче - да. Но это не хорошо для ООП.
Джава слишком мейнстримовская:
Она постоянно все вбирает (все подряд, что нравится программистам) но почти ничего не убирает. Но мы же тащим в дом все что используем.
Никого это не волнует, что Java код загромождается... поскольку он выполняется на локальных машинах, производительность которых стремительно растет, компилятор может что-то почистит еще... это все развращает.
Должна быть цельность языка, а Java превращается в монстра, типа C++ которого уже никто не понимает. Смешение идеологий принесет только вред. Это движение убьет язык ... впрочем может и к лучшему - освободится место для новых.
http://razbor-poletov.com/2016/09/episode-116.html
Комментариев нет:
Отправить комментарий