undefined

Еще одно объяснение ООП (слабая связность, четкие функции)

Java Core
1 уровень , 3 лекция
Открыта

— Привет, Амиго! Хотела тебе рассказать еще об одном преимуществе использования ООП. Видишь ли – программы больше напоминают не строения, а животных. Их не строят, их выращивают. Разработка — это постоянные изменения. В строительстве ты можешь иметь хороший план и четко ему следовать. В случае с разработкой программ – это не так.

Очень часто что-то нельзя сделать тем способом, который ты себе наметил, и приходится многое переделывать. Еще чаще меняются требования заказчика.

— А если заказчик проекта дал очень точную его спецификацию?

— Тогда взгляни на ситуацию во времени. Успех продукта приведет к тому, что заказчик захочет выпустить его новую версию, а затем еще и еще. И, конечно, нужно будет всего лишь добавить «небольшие изменения» в уже существующий продукт. Поэтому разработка продукта – это последовательность постоянных изменений. Только масштаб времени разный. Каждая новая версия может выходить раз в неделю, раз в месяц или раз в полгода.

— И какой вывод можно сделать из всего этого?

— Внутреннюю структуру продукта нужно поддерживать в таком состоянии, которое позволит внести значительные (и не очень) изменения с минимальными переделками.

— И как такое сделать?

— Мы уже говорили, что программа состоит из объектов, которые взаимодействуют между собой. Давай нанесем на доску все объекты нашей программы, обозначив их жирными точками. И проведем от каждого объекта (точки) стрелочки ко всем объектам (точкам), с которыми он взаимодействует.

Теперь мы будем объединять объекты (точки) в группы. Точки должны быть объединены в группу, если связи между ними гораздо интенсивнее, чем с остальными точками. Если большинство стрелочек от точки идет к точкам ее же группы, тогда разбиение на группы произошло правильно. Точки внутри одной группы мы будем называть сильно связанными, а точки из разных групп – слабо связанными.

Это называется «принцип слабой связности». Программа разбивается на несколько частей, часто слоев, логика которых сильно завязана на их внутреннее устройство и очень слабо на другие слои/части. Обычно взаимодействие слоев очень регламентировано. Один слой может обращаться ко второму и использовать только небольшую часть его классов.

— Тот же принцип «разделения на отделы» только в большем масштабе?

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

— Выбраны удачно. А что будет, если они выбраны неудачно?

— Тогда «запас изменений» быстро иссякнет и придется переделывать всю систему. Такое приходится делать время от времени. Нельзя предугадать, что будет в будущем, но можно свести количество таких переделок к минимуму.

— Хорошо. Про пользу такого разделения я понял, а ООП тут причем?

— Выбор структуры отделов и способа их взаимодействия – это «принцип Абстракции». В программировании он используется для определения, на какие части лучше разбить программу, и как эти части должны взаимодействовать. Данный принцип также можно применять к разделению полученных частей, пока мы не разобьем программу на отдельные классы.

— А сокрытие внутренней структуры этих частей, и жёсткие ограничения на взаимодействие с другими частями – это Инкапсуляция, да?

— Именно. Инкапсуляция + Абстракция – это краеугольные камни ООП. Хорошая программа обязана следовать этим двум принципам. В дальнейшем мы рассмотрим остальные принципы и поймем, какие преимущества они дают.

— Очень интересно. Жду с нетерпением.

Комментарии (60)
Чтобы просмотреть все комментарии или оставить свой,
перейдите в полную версию
Жека 27 уровень, Москва
22 апреля 2021
вот эта сереневая фигня под названием "Амиго" своми вклинивающимися диалогами сбивает мне все настройки и концентрацию для адекватного восприятия информации. Бесит! выскочка, всегда влазиит,когда не спрашивают.
Арсений 32 уровень, Москва
23 марта 2021
После коллекций, всяческих вложенных классов, лямбда выражений, потоков и их методов, от которых из ушей кровь идет, мне снова рассказывают про ооп, кайф))
🦔 Виктор 20 уровень, Москва Expert
6 декабря 2020
Уже лучше, гибкость и масштабируемость, а ещё очень понравилось выражение «запас изменений», по истечению которого придется переделывать всю систему. Тут уже лучше доходит, что абстракция — это упрощение чего-то сложного для лучшего понимая и управления этим, разбиение одного большого, запутанного комка на понятные секции, каждая из которых выполняет свою задачу, внутри этих секций все роли чётко прописаны и распределены, поэтому кто попало с улицы не может с наскока вмешаться и устроить хаос в отлаженной системе. *мысли в слух* Всё получится! p.s. Даже здесь дублируют статью про принципы ООП, настолько она хороша, не пропускайте!
Евгений Кафанов 16 уровень, Москва
24 октября 2020
Блин, почитал комменты и офигел. Думал тут будут зеленые джуны (хотя возможно так и есть, возможно!), но комменты читаются как будто тут очень бородатые кодеры сидят.
Will Fight 27 уровень
14 октября 2020
Видишь ли – программы больше напоминают строения, а не животных. Надо больше света людям. Выбор - прорубить окна или добавить лампочек? Решение - что более дешёво. Надо надстроить третий этаж. Но извини - сначала переделай фундамент. Решение - рефакторинг ядра. Технический долг копится? Это ветшание внутренних коммуникаций (трубы, проводка....) Надо переехать на другую платформу? Старое здание оставляешь арендаторам, строишь новое p.s. а маленькие программы - это вечно недостроенный частный дом
Е К 33 уровень, Краснодар
10 октября 2020
Абстракция - это для ленивых капиталистических кодеров! Товарищ! Даёшь фул кодинг для каждого класса!!💪
Pavel Miroshnichenko 12 уровень, Москва
8 октября 2020
такое чувство, что как народ из syntaxisa выходит, так сразу на нобелевку подается)) а сам про себя думаю "все равно нужно будет почитать Bruce Eckel Thinking in Java, наверняка там уже все эти вопросы автором вдоль и поперек обмусолены))
Pavel Kurchavov 32 уровень, Тверь
27 июня 2020
Мне одному кажется, что тут абстракцию описывают точь-в-точь как декомпозицию??
Anton 13 уровень
12 февраля 2020
Насчет абстракции. Практически все компьютеры работают в двоичной системе 0 и 1 все что "выше" это уже абстракция. Все наши эти if, else, ArrayList все это абстракции по сути своей. И даже 0 и 1 это абстракция, а изначально это состояние транзистора - включен/выключен. И транзистор по сути абстракция, через которую получается управлять потоком электронов, то есть током. И понятие электрический ток - тоже абстракция. А дальше уже квантовая физика :-) Хотя там абстракций еще больше...
Олег Гавшин 22 уровень
5 февраля 2020
Как я понял это проектирование программы по принципу модульности. Реализация каждого модуля внутри уникальна и сокрыта (инкапсулирована) от других. При этом имеет сильные связи между элементами находящимися внутри модуля, а с элементами других модулей слабые, что позваляет безболезненно и эффективно проводить модернизацию выполняемых задач данного модуля не оказывая существенного влияния на работу других модулей.