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

ну я

если вы думали, что я забила на Яндекс Лекториум, то вот и нет ✨

послушиваю иногда фоном лекции, что-то понимаю, что-то нет, но в голове зато хоть что-то остаётся. и сегодня я попала на СУПЕРСКУЮ лекцию про архитектуру кода для джавистов: конечно, из понятного мне было процентов 30, но какие они, эти 30!!

читал лекцию Сергей Федосеенков, глава отдела разработки битуби продуктов Маркета, и иллюстрировал всё примерами из жизни и практики (круто и наглядно!). иногда на каком-то базово-гуманитарном уровне не верится, что все эти сложные и абсолютно человечески реализованные сервисы — это просто набор компуктерных команд, методов, переменных и классов. но вот ты видишь, как знающий человек показывает тебе на примере кода, как реализуются бизнес-стретегии, как функционируют соединения к базам данных, в которых хранятся условные заказы с чипсиками — и ну это с ума сойти, это РЕАЛЬНО 🥹

часовую лекцию пересказывать, конечно, не стану, если захотите, она лежит 👉🏻на ютубе в записи. но вот что мне хорошо запомнилось и чем хочу поделиться: какие принципы хорошей архитектуры кода существуют?

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

📌 kiss: keep it simple, stupid. мне кажется, знаменитейший принцип, знакомый всем, от новичков до супер-прожжённых прогеров. не нужно решать задачу сверх-сложными методами, а лучше инкапсулировать логику совсем просто, супер-наивным способом, чтобы потом всегда можно было вернуться к переработке кода или даже всей архитектуры и не потеряться в трёх тысячах сосен :') в трёх соснах блуждать приятнее. а может быть, окажется, что этих трёх как раз и достаточно

📌 есть ещё пять принципов SOLID, спикер не стал останавливаться на каждом, но пояснил, что это аббревиатура, и каждая буква в ней — какой-то принцип объектно-ориентированного программирования. я почитала об этом отдельно, очень хорошие и важные принципы, которыми мы уже сейчас на занятиях пользуемся и сами того не знаем :) напишу о них отдельный пост завтра-послезавтра!

в общем, час пролетел продуктивно: по большому счёту я вдохновлялась сложной терминологией и пыталась на каком-то интуитивном уровне понять, о чём идёт речь 😂
но и без полезностей не ушла! так что продолжаю ратовать за подход к обучению «вписывайся в любые учебные авантюры, а там уж если и поймёшь процентик, то тоже хороший результат» 👀

это я, когда уезжаю трогать песок у моря в другие города по выходным

нашла целую подборку на гитхабе всяких полезностей по джаве: руководства, статьи, учебники. там не только джава, на самом деле, по индексу выше можно найти что угодно ❤️‍🔥

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

пусть я и послушаю лекцию по касательной, но 1) я её потом ещё разок пересмотрю и 2) так я всё равно сделаю хоть что-то. а хоть что-то лучше, чем ничего 🤞🏻

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

я и мои домашки:

за всю неделю, что у меня болел зуб, я 🤕🦷:

1. не пропустила ни одной лекции и жёстко собой горжусь!!

2. возобновила решение домашек: начинаю с наиболее актуальных, затем возвращаюсь к стареньким долгам. не сомневаюсь, что скоро выполню все 🍀

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

4. и мощно возвращаюсь с кучей постов на давно интересовавшую меня тему, с которой хотелось разобраться как следует. wait for it 🤞🏻✨

итак, руки наконец-то ✨дошли✨

встречайте: сегодня весь день в эфире — принципы SOLID для всех, кто постигает таинство ООП.

в основе этого и последующих постов — материал, найденный на родном хабре 👈🏻

давайте начнём с предисловия: SOLID — это аббревиатура. или, вернее, мнемонический акроним. про каждую буковку поговорим отдельно, а пока — вот общая картинка 👀

идея названия принадлежит Майклу Фэзерсу, а сформулировал принципы программист Роберт Мартин. идея была простая, но важная: выделить самые важные правила ООП, благодаря которым можно будет создавать легко поддерживаемые и расширяемые системы. словом, гибкая и адаптивная разработка без SOLID — это не солидно 😉

🎯 s: single responsibility
(принцип единственной ответственности)

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

в соответствии с этим принципом программисты разделяют различные типы поведения, чтобы изменения, внесенные в одно поведение, не влияли на другие.

каждому классу — своя логика!

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

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

🚪o: open-closed
(принцип открытости-закрытости)

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

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

здесь на помощь приходят абстракции: они представляют собой абстрактные базовые классы или интерфейсы, которые определяют общее поведение или функциональность. и на этом всё. просто эдакий скелет 💀✨

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

☕️ l — Liskov substitution
(принцип подстановки Барбары Лисков)

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

тяжко зашло определение? мне тоже 😳 сейчас попробуем разобраться.

если ОЧЕНЬ простыми словами, то идея такова: важно, чтобы класс-потомок был способен выполнять те же действия, что и класс-родитель. в противном случае возникает риск возникновения ошибок.

некоторые изменения могут повлечь за собой серьезные архитектурные проблемы. самая главная из них — это сломанный полиморфизм. если мы решим изменить в какой-то момент сигнатуру метода в классе-наследнике, мы в итоге получим несовместимых родителя и ребёнка 👶🏻 это не дело!

то ли дело качественно выстроенная иерархия типов 🙌🏻

⚡️i: interface segregation
(принцип разделения интерфейсов)

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

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

кому нравится делать лишнюю работу? ну вот и интерфейсам не особо 🤖

вернёмся к домашке: предположим, что мне нужно посчитать не только площадь фигур, но и объём, потому что среди них затесались условные шар и куб. мы хотим, чтобы все фигуры имели метод для вычисления объема, но что делать, например, с плоскими квадратами? в классе квадрата реализовать метод вычисления объёма — не дело: интерфейс, который будет содержать метод для вычисления объема, заставит класс квадрата реализовать его пустым. мартышкин труд 🥴

другое дело — если мы создадим отдельный интерфейс с методом вычисления объёма и имплементируем от него классы объёмных фигур. вот тогда всё будет красиво и без нарушения логики.

🏆 d — dependency inversion
(принцип инверсии зависимостей)

мы добрались до последнего принципа, ура!

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

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

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

кажется, тут картинка будет красноречивее всего 🥹

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

принципы SOLID дают вполне себе хорошую картинку, почему и зачем. и заодно — представление о том, насколько хрупким и одновременно с этим мощным является ремесло проектирования приложений 🏋🏻‍♀️✨

спасибо, что были сегодня со мной! пыталась разобраться в этих тонкостях сама — и буду рада, если окажется, что заодно помогла что-то объяснить и вам 🥂