Шаблоны разработки. Шаблоны GRASP

[@AlexK-md8vx]

Замечательный курс! Отлично систематизирует, раскладывает все по полочкам! Спасибо, Сергей!

[@geekacademytv]

Отличный курс! Сергей, спасибо огромное !

[@yataganenko]

Да что за скромность. Просто аху***ый курс. Безмежно вдячний! :)

[@yataganenko]

***** Это Вам спасибо. Ждем еще курс по Java :)

[@iromanochka]

- Что такое "делегирующий" все знают? - да... - Ну, хорошо - наверное 35:03

[@Das.Kleine.Krokodil]

Классно когда лекции читает практик

[@mr_DorianGray]

Огорчен. Когда мы писали систему управления платежными терминалами, то все обработчики событий UI я вынес в отдельный класс, там же синхронизировал ajax и искренне верил в гениальность своего изобретения... оказалось, что это просто реализация шаблона "Контроллер"

[@белка-у8б]

Не огорчайся - это все можно будет в конечном итоге автоматизировать

[@АлександраТрускова-ь3ь]

Спасибо за крутую ЛК, будь у меня такой преподаватель в университете я бы туда ходила день и ночь ! P.S Вроде на данный момент есть связанность и свяЗНость ( вместо зацепления), если я правильно понимаю о чем идёт речь )

[@icywiener5421]

--Что такое "делегирующий"- все знают? -Да...(шепотом:) наверное...

[@sobaleubel]

Да это же Гилфойл =)

[@МихаилМорозов-ц1г]

В том смысле что он так же предвзято относится к индусам?

[@korobkofff]

Отличный курс! Если б ещё рядом с камерой кто то не жевал сопли и не шмыгал носом - в наушниках это слушать просто адь.

[@svyatoslavs945]

Мне кажется, Cohesion в данном контексте стоило бы переводить как "сфокусированность"

[@svyatoslavs945]

@@SergeyNemchinskiy в наших силах поменять )

[@WillSom056]

Блин, оператор громко дышит. А в общем как всегда классная лекция!

[@Dmytrii_Havryliuk]

он дорожки занюхивает

[@ilnurryazhapov]

У него дыхание захватывает от подачи Сергея))

[@wd_1]

нахер ты это сказал, сразу начал слышать

[@dzen1234]

0:42 Что-то не вижу никакой рекурсии. Всего лишь аббревиатура.

[@ИгнациусКоппер-к6ч]

@@0imax - первая буква расшифрована как General, а не GRASP, так что я тоже не вижу рекурсии. (но это всё мелочи и придирки, конечно же)

[@maxkomarow]

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

[@maxkomarow]

Спасибо за ответ, я имел в виду следующее - если класс А использует класс Б, то что используется чаще: - класс А в своем конструкторе сам создаст себе класс Б. - мы юзаем DI контейнер, который создаст А и напихает в него Б, т.е. отвечает за все зависимости. Буду признателен если подскажете, спасибо.

[@Dmytrii_Havryliuk]

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

[@ВикторГиль-ф2ф]

Согласен, отличный курс. Единственное, фраза "бизнес логика должна быть однопоточной и не содержать mutex" возможно стоило сказать немного иначе. Бизнес логика ДОЛЖНА быть многопоточной (иначе зачем многоядерные системы), но обращаться куда либо обязана в пределах своего контекста потока. А mutex наоборот, нарушают многопоточное выполнение, т.к. блокируют потоки. Тем более что в том же EE уже есть контекст (с соединением к базе данных из пула соединений...) у бинов, и у каждого там свой поток. Но это я возможно придираюсь.

[@ВикторГиль-ф2ф]

Виктор Гиль А вместо ссср лучше анекдот, про бизнес логику в тюрьме ( как в Городке). Тарелка, ложка и суп - это контекст. Бизнес логика - "это что такое, мне же мясо положено" Контроллер - "положено,значит ешь". Бизнес логика - "да в том то и дело, что оно не положено". Контроллер - "не положено, не ешь".

[@ВикторГиль-ф2ф]

Виктор Гиль Кстати конструктор не совсем обычная функция. И с точки зрения компилятора тоже. Это единственная функция, которая вызывается всегда, перед использованием класса. Даже если в конструкторе потомка не указать вызов конструктора предка, он все равно вызывается компилятором неявно. Потом могут быть проблемы с исключениями при отладке, строчки нет а исключение есть... поэтому с ресурсами в конструкторах не работают, как в обычных функциях.

[@ВикторГиль-ф2ф]

Виктор Гиль Конструктор даже может быть вызван до старта самой программы. public static TestConstructor tc = new TestConstructor(); public static void main(String[] args) { System.out.println("Hello!");

[@aleksandrsavvopulo5473]

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

[@EyeOfInfinity-t5g]

Касательно заявления про однопоточность бизнес логики. Если у нас есть хендлер, который вызывают внешние клиенты, то очевидно что каждый такой вызов - это отдельный поток (ну или горутина в go и т.п.). Ставить все вызовы в очередь - это полная дичь. Обработка должна быть параллельной иначе ни о каком highload речь идти не может. Данные у нас общие и доступ к ним надо защищать мьютексами - это раз. Далее, если нам необходимо сходить в другие сервисы (а в микросервисной архитектуре это надо почти всегда), то вполне вероятно мы можем сделать это параллельно, а не последовательно. Т.е. мы опять получаем многопоточный код. Никаких проблем с юнит тестами нет - просто пишем тесты на элементы бизнес-логики отдельно. Фраза "с базами сейчас работают ORMы" - тоже не однозначна. По крайней мере там, где высокая нагрузка на операции с БД - никаких ORM нормальный архитектор не допустит.

[@KhSlavjan]

так, как тут все перфекционисты предлагаю немного оптимизировать перевод терминов: Low Coupling назвать Низкой Зависимостью, а High Cohesion - Высокой логической Связанностью, лучше наверное Ограниченной Специализированностью (или как-то так).

[@ИванИванов-в7е3у]

+Sergey Nemchinsky какой смысл что либо-придумывать, если термины официально переведены, с моей т.з. идеально - это низкая связАННОСТЬ (от слова связь, зацепление, сопряжение) (ru.wikipedia.org/wiki/Зацепление_(программирование)) и высокая связНОСТЬ (от вязкости, прочности, силы взаимосвязи) (ru.wikipedia.org/wiki/Связность_(программирование)). В этом контексте перевод cohesion, как "зацепление" противоречит общепринятой логике. Но это просто термины, введенные для обобщения принципов, а так изложение максимально доступное, практически без привязки к ЯП. Большое спасибо!

[@usersbit]

@@ИванИванов-в7е3у Сергей ориентируется на перевод книги Крэга Лармана. В то время, в Википедии участники переводов не могут или пока ещё не пришли к единому переводу: ru.wikipedia.org/wiki/Обсуждение:GRASP ru.wikipedia.org/wiki/Обсуждение:Связность_(программирование) ru.wikipedia.org/wiki/Обсуждение:Зацепление_(программирование)

[@MindsetOfMusic]

Все хорошо, но правильно говорить так : Класс должен иметь Слабое зацепление (Low Coupling) и Высокую связность (High Cohesion). Зацепление это за какие классы класс зацеплен (зависит) то есть он должен иметь минимум зависимостей, а связность значит на сколько он обладает свойством СВЯЗНОСТИ то есть на сколько легко его использовать другим классам , должно быть легко значит и связность должна быть высокой. Еще можно сказать что зацепление это СВЯЗАННОСТЬ, таким образом не надо путать свЯзность и связАнность. ru.wikipedia.org/wiki/GRASP

[@usersbit]

Сергей ориентируется на перевод книги Крэга Лармана. В то время, в Википедии участники переводов не могут или пока ещё не пришли к единому переводу: ru.wikipedia.org/wiki/Обсуждение:GRASP ru.wikipedia.org/wiki/Обсуждение:Связность_(программирование) ru.wikipedia.org/wiki/Обсуждение:Зацепление_(программирование)

[@usersbit]

Отличная статья Cohesion and Coupling: the difference enterprisecraftsmanship.com/posts/cohesion-coupling-difference/

[@МаксимАлексеев-ч4й]

Диаграммы первого примера с Low Coupling совсем чёт не отражают сказанного. "Low Coupling - низкая связанность. Мы хотим чтобы между компонентами было как можно меньше стрелочек." В итоге на диаграмме "ДО" и "ПОСЛЕ" количество стрелочек одинаковое. Этот пример точно не для демонстрации Low Coupling

[@alexpepper2146]

Information Expert не значит всё хранить в 1 классе, это больше про разбивку по доменам и смысловым операциям, по типу информации. на примере даже того же калькулятора, мы можем иметь калькулятор который считает покупки из продуктового, а так же отдельный клас калькулятора который будет счетать из косметического магаза, и т.д. а от услышенного складывается впечатление что только 1 класс должен использовать orders и т.д. "молодые" могут запутаться тута..

[@DasBrennendeHerz]

Можно и в таком контексте воспринимать. И в плане ответственности классов и в плане ответственности пакетов, и так как Вы написали. Это ведь не энтерпрайз-паттерны, а ООП-паттерны. И кроме того нельзя забывать главное - "паттерны не являются законченным образцом проекта. Это описание или образец того, как можно решить задачу таким образом , чтобы это решение можно было использовать в различных ситуациях". Уже встречал на ютубе преподавателей которые шаг в сторону от канонического применения паттернов считают нарушением и пытаются присобачить решение к другому паттерну, хотя это далеко не всегда верно.

[@kai3341]

Касательно датчика много нюансов. Разделение класса на 2 имеет смысл, когда наша абстракция -- измерение, и теряет смысл, когда наш уровень абстракции -- датчик. Что делать, если значения датчик отдаёт парами? Класс должен отбросить вычитанное значение, с которым он не работает? Что делать, если физический смысл, помимо значений по отдельности, имеет именно вычитанная пара? Заниматься фикцией и надеяться, что собранная вышестоящим классом пара будет достаточно точна? Не дай боже с таким подходом писать медицинский софт Вся эта лирика о чём? Об уровне абстракции (с чем мы работаем) и здравом смысле

[@vasia212]

[kōˈhēZHən] же...

[@gen7891]

Сильная связность и слабая связанность. Просто переводы книг гавеные. Проектирование это вообще творческий процесс, который сопровождается везением.

[@ax3914]

ужасный оператор.. ,курс отличный