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

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

📌 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 дают вполне себе хорошую картинку, почему и зачем. и заодно — представление о том, насколько хрупким и одновременно с этим мощным является ремесло проектирования приложений 🏋🏻‍♀️✨

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

признаюсь: я переживаю все стадии горевания 🥺

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

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

но!

вот что важно:

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

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

👉🏻 в конце концов, кто запрещает мне слать мемы и иногда задавать вопросики в слаке?.. как в старые добрые!

в общем, резюмируя:

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

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

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

спасибо, Марсель @marsel_sidikov, ты бэст оф зэ бэст тичер эвер! без тебя я б так долго не продержалась — но раз уж я уже тут, то выхода нет: двигаемся дальше 💪🏻

мне СУПЕР нравится эта концепция подготовки к будущим собесам 👀

буду пробовать уже сейчас и поднимать градус стресса очень умеренно