Евгений, спасибо за материал! Тоже удивляюсь, почему на моих проектах не используют uml. Буду благодарен за углубление в тему uml и паттернов.

3:28 лучшее объяснение про разницу между композицией и агрегацией из всех, что я видел

Полезно! Тоже не так давно для себя понял, что UML будет очень полезен в повседневной практике при написании/исправлении ООП кода

Спасибо Вам за труд. Слушаю Вас уже больше года

Спасибо вам за труд!

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

Воу... Спасибо за видео. Очень не хватало такого видео

ну прям очень крутая подача!!! качественно и доходчиво!

Интересный гайд! Спасибо!

Для тех кто в теме и так все понятно, для тех кто не в теме лучше показывать на кошечках и собачках

Мегалайк! Очень грамотное объяснение)

Спасибо!!!

Спасибо!

Если это примеры на Java, то хочу сообщить, что начал учить этот язык программирования (учил раньше другой). Подскажите, есть ли продолжение по теме разработки ПО через конструирование диаграмм в UML в другом видео?

Дякую за відео! Чудові пояснення!

Лучший канал.

Крутая тема. Мы на работе постоянно пользуемся UML (под 'мы' имею ввиду и junior-ы [добавить какой-нибудь атрибут или вычислимое поле], middle-ы [спроектировать некую фитчу], senior-ы [ну тут понятно]). Во всех проектах используем uml-генератор, что очень сильно упрощает разработку

@SerhiiZhydel

5 жыл бұрын

Jin zakk что за uml-генератор?

@skarabeydm

2 жыл бұрын

@@SerhiiZhydel ответа так и не последовало...

@academai11

Жыл бұрын

@@SerhiiZhydel гуглить пробовали?))

@vaccino3668

6 ай бұрын

мы всё ещё ждём

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

@S0ERDEVS

5 жыл бұрын

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

@SerhiiZhydel

5 жыл бұрын

Software Engineer - Soer а в чем тогда роль архитектора? это просто самый скиловый чувак в конторе и все?

@S0ERDEVS

5 жыл бұрын

@@SerhiiZhydel видимо говорим о разном, архитектор (у нас по крайней мере) занимается архитектурой всего приложения - деление на модули, точки подключения, распределенное взаимодействие и так далее. Так же переодически приходится писать код, делать рефакторинг, но это не основная задача (есть "играющие" архитекторы, есть "чистые" архитекторы, у нас все "играющие" - т.е. пишущие код). Архитектор понимает какие технологии нужно затянуть в проект, продумывает схемы отказа, восстановления и прочие вещи связанные с бесперебойной работой. Может, конечно, и диаграммы классов делать, продумывая код до самых мелочей, но это на практике не стоит того. А на уровне кода работает тимлид и программисты, архитектор туда особо не лезет и уж точно не следит за состоянием кода каждого программиста. Так вот, если мы говорим про код, то никто не прорабатывает диаграммы классов заранее, пишут код по накатанным схемам. И никто не продумывает код ну уровне функий, классов и т.д. Архитектору важно, чтобы код выдавал результаты в рамках заданной SLA и спецификации или иной документации на проект. Важно понимать, что проект != код.

@S0ERDEVS

5 жыл бұрын

@@SerhiiZhydel вот было видео, где я рассказывал про архитектора - kzread.info/dash/bejne/g6hlq9qhn7SYlNo.html

@SerhiiZhydel

5 жыл бұрын

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

а какие програмки посоветуете для создания диаграмм?

Супер!. Огромное спасибо, очень зашло. Однако не очень понятно, почему не показны связи на контекст. И в методах на схеме тоже не отображена ссылка на контекст, как будто он совсем не причем. Непонятно какий связи всетаки необходимо отображать а какие нет. Связи создания тоже не отображаются, а например IDEA их очень аккуратно рисует.

Какую программу использовали для рисования UML диаграмм?

Добрый день. Мне кажется, что на 10:54 у вас не агрегация, а композиция. Там закрашенный ромбик.

Примеры показаны на каком языке программирования?

Каким uml редактором пользуетесь? Спасибо

@S0ERDEVS

5 жыл бұрын

Мне выше крыши хватает draw.io

Мне кажется, что в UML для данного кода, должно быть другое отношение, а именно агрегация, а не композиция т.к. state будет переопределяется. Или я что-то не правильно понял?

@Cronikx

3 жыл бұрын

Не совсем. Агрегация и композиция говорят не о том может ли объект который использует, поменять один используемый объект на другой, а о том может ли используемый объект существовать отдельно от объекта, частью которого он является. Иными словами, может ли часть существовать отдельно от целого. В примере из видео, state создается всегда внутри объекта context и если context по каким то причинам уничтожится, то вместе с ним умрет и его state.

Мне кажется, что это видео слишком мало отличается от статьи на Вики потому, что нету реального места применения. Не всем достаточно слов, что это для реализации state machine.

а это какая связь? class A{ constructor(){ someProp = B::someMethod() ; } } ; очень часто пользуюсь просто вызовом статических методов в классах , это удобно , т.к. разбивает логику приложения на отдельные элементы, при этом в клиентском коде ты ничего не должен знать про их реализацию, НО все равно зависимость существует, я всегда считал что это пример "Использования"

По поводу нелюбви к UML, это интернациональное явление. Вот в этом видео kzread.info/dash/bejne/qmZh1LWnmNPdYMo.html во вступлении ведущий приводит только некоторые из знакомых ему причин для неиспользования UML. Сам я считаю, что визуализация важна, а изучение шаблонов и приёмов с UML очень способствует развитию инженерного и абстрактного мышления. В работе, увы, применяю его не так часто, хотя работаю над этим тоже.

понравилось, но ничо не понятно))

перепутал стрелочки ассоциации и использования

@S0ERDEVS

3 жыл бұрын

Советую погуглить этот вопрос.

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

@S0ERDEVS

5 жыл бұрын

Не только для Java, любой ООП язык подходит. Есть и для функциональных языков шаблоны, но диаграмм классов, естественно, у них нет.

@iamboldaslove

5 жыл бұрын

Software Engineer - Soer, «подходит» условно, так как терминология другая, в Swift и objective-C интерфейс - это протокол и т.д.

@AndriiKuftachov

3 жыл бұрын

@@iamboldaslove как не назови, интерфейс - это контракт, который обещает соблюдать класс для внешнего взаимодействия.

Никогда не мог запомнить в какую сторону рисуют стрелочки меэжу двумя классами! От старшего класса (который пользуется) к тому классу, которым пользуются?