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

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

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, ты бэст оф зэ бэст тичер эвер! без тебя я б так долго не продержалась — но раз уж я уже тут, то выхода нет: двигаемся дальше 💪🏻

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

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

я пропала, чтобы внезапно ворваться с новостью!!

В ПОНЕДЕЛЬНИК НАЧИНАЕТСЯ МОЙ ПЕРВЫЙ ПРОЕКТ 🥹✨

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

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

а что я делала всё это время?

умирала от жары, допиливала домашки (потому что моё чувство прекрасного не позволяет мне оставить нерешёнными даже доп. таски со звёздочками), читала всякие материалы про хэшкод, хэшмапы и хэшсет. начала читать Эффективное программирование (Дж. Блох)!! ввела привычку: книжки — на пляже по воскресеньям. никакой учёбы один раз в неделю, но книжки можно 😂 из простого житейского — была на концерте любимой группы и плавала в море 🌊

в общем — жизнь!..

тема моего первого проекта ударила по самому больному:

💸 КОНВЕРТЕР ВАЛЮТ 💸

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

это оказалось СИЛЬНО сложно. нас в команде трое, мы все умные ребятки, и у каждого из нас — своё видение программы. оказалось, даже кнопки меню можно обсуждать час и больше, а что уж говорить о том, где хранить данные, как их обрабатывать и отдавать пользователю результат 😬

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

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

ну ничё, будем исправлять!

сегодня день защиты, допиливаем остатки программы ✨

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

потом расскажу, как всё прошло и что наша программа умеет 👋🏻

ЗАЩИТИЛИСЬ!!!!!!!!!! НИЧЕГО НЕ УПАЛО 🎊🎊🎊