Интересный доклад Игоря Беспальчука:
Мысли, во многом, созвучны моим.
12 комментариев
Добавить комментарий
Предыдущая запись: Дьявол Гуд Бай
Следующая запись: Ху есть мистер Component?
Интересный доклад Игоря Беспальчука:
Мысли, во многом, созвучны моим.
Постоянная ссылка
В продолжение доклада решил попробовать поприкидывать, как могло бы выглядеть в коде описание некоторой структуры компонент с явными отношениями часть-целое.
А параллельно — рисовал схемки в Visio.
Промежуточные результаты можно посмотреть тут:
https://github.com/iamhere2/HLCD-Researches/tree/master/ChessApp
В качестве примера я взял консольное приложение для игры в шахматы (ну, а почему бы и нет?).
Даже на этом маленьком масштабе есть что подизайнить на верхних уровнях, и сразу возникают интересные вопросы.
В частности — дизайн верхнего уровня незаметно получился не очень-то зависящем от собственно шахмат.
И это поднимает вопрос удобства работы с абстрактными типами значений, при том, что должно быть по-прежнему ясно, что это значения, а не что-то еще.
Собственно, если поглядеть на схемку
https://github.com/iamhere2/HLCD-Researches/blob/master/ChessApp/dgm/Images/ChessApp%20-%20components.png
то наглядно видно, почему так важно отделять значения от компонентов и интерфейсов. Без этого различения невозможно понять (машине), что, например, Turn и BoardState — это то, что _передается_ между компонентами в их взаимодействии, а не еще один очередной компонент с
каким-то собственным интерфейсом. «Классическое» ООП тут не годится — там «все есть объект» и все тут, ничего не понятно без применения мозга.
Постоянная ссылка
Примитивных типов не бывает. Бывают типы базовые или ещё лучше — фундаментальные. Отдельно в качестве плюса отмечу, что у докладчика из видео (что хвалится своим системным мышлением) — на 5 слайде — вход развёрнут в сторону выхода. У вас на картинке по второй ссылке — это сделано более грамотно: входы слева — выходы справа.
Постоянная ссылка
1) Прошу немного сбавить градус дискуссии, я про «хвалится…»
2) Есть мысль поговорить вместе (zoom). Вдруг из этого что-нибудь получится?
Постоянная ссылка
Совершенно не против, но боюсь. что Zoom ставить придётся и регистрировать. Могу предложить как альтернативу Скайп или Вайбер.
Постоянная ссылка
Не придется. Для оперативных вопросов у нас есть чат в Скайпе и Телеграмме. Давайте вас подключу к нему. Напишите логин, я не буду выставлять в блог сообщение с логином.
Постоянная ссылка
06:30 Докладчик описывает логику работы на разных уровнях — абстракция это называется, не? Что касается «не важно, как работает железка» — я не соглашусь. В сущности ,программа — ровно такая же железка. Есть входы, есть выходы, есть внутренняя логика. Причём свои входы-выходы, своя логика — есть на каждом уровне абстракции.
10:00 «Мы не увидим модули этапа разработки во время этапа исполнения». Ну, как-то не могу согласиться. У меня так не бывает)) Далее на слайде 9 — откровенные циклические зависимости (не входы/выходы, а я так полагаю — импорт). Совершенно нет никакой иерархии. Для меня это ужас-ужас))) Я понимаю, что докладчик описывает типичную ситуацию, но мне смотреть на это несколько странно.
15:20 слайд 12 — автор явно смешивает понятие объекта и компонента. Также смешивает понятие абстракции как интерфейса, и абстракции как идеи.
16:21 Автор правильно мимоходом замечает, что UML практически умер. И сам тут же показывает слайд 13 в котором зачем-то раскрывает детали компонентов. На этом уровне — важны только входы-выходы. (* И опять входы выходы на части компонентов расположены кое-как — в такой диаграмме разобраться невозможно. Это не есть системный подход *)
23:00 Герметичность компонентов — разумеется. Смысл делать абстракцию, если она течёт во все щели? По-моему — это очевидно. «Все объекты в языках одного уровня». Ну уж нет. Есть возможность скрывать части объекта, собственно — у объекта должен быть только интерфейс и никак иначе.
Заключительные слайды — в-целом согласен. От себя вставлю, что Клеменс Шиперски во многом задачу компонетного подхода решил вполне сносно. Хорошие компоненты приводят к сносной архитектуре (по крайней мере — такой код можно долго сопровождать).
29:00 «Микросервисы — усечение проблемы до головы». Я бы не стал делать столь категоричные утверждения. Микросервисы — прекрасное решение для увеличения степени масштабирования программной системы. Также весьма удобно «на ходу автомобиля менять ему колёса». И это точно такое же решение по фиксации интерфейсов.
34:00 Содокладчик говорит о вызове, как взаимодействии компонентов. Это неудачная терминология. Я предпочитаю говорить «потребляет». Что. впрочем, дальше по ходу содоклада отмечается как введение в заблуждение. Вообще, много таких глупых калек существует (например, вместо цепь — список, вместо переопределение — перегрузка и т. п.)
Конечно, тема важная, докладчику — лайк, но тут бы надо му записать серию лекций, потому что галопом по европам — слишком крупные шаги.
Постоянная ссылка
Отвечу по некоторым пунктам, которые мне понятны. Надеюсь, это пояснит сложные места.
* «Докладчик описывает логику работы на разных уровнях — абстракция это называется, не?»
Нет, речь про уровни системной организации. Ваше тело, к примеру, это не абстракция над органами. Автомобиль — не абстракция над его узлами, агрегатами, и деталями. Отношение «часть-целое» — совсем не то же самое, что отношение «абстрактное-конкретное».
Постоянная ссылка
* «Мы не увидим модули этапа разработки во время этапа исполнения». Ну, как-то не могу согласиться.
Тут можно сказать мягче. Некоторые их «следы» иногда остаются. Но один-в-один — практически никогда не увидим. Сопоставьте это с тем, что в физических системах («самолет») вы логистическую единицу («насос с серийным номером #12345 купленный тогда-то и за столько-то») найдете как временное воплощение того или иного компонента времени исполнения («насос топливного бака левого крыла»). В программнх системах такого нет. Модулем был код на ЯП или готовая .dll, но в момент исполнения (в памяти!) от них чаще всего остаются «рожки да ножки», которые никто не наблюдает, да и не важны они уже.
Постоянная ссылка
* на слайде 9 — откровенные циклические зависимости (не входы/выходы, а я так полагаю — импорт). Совершенно нет никакой иерархии. Для меня это ужас-ужас)))
Я и описываю это как ужас-ужас. Тот, который все мы имеем. Слайд — условный, и в первую очередь призван проиллюстрировать исчезновение/отсутствие компонент верхнего уровня как проявленных в языке предметов работы на уровне разработчика. «Совершенно никакой иерархии» — именно так. У нас нет средств выражать иерархии, основанные на отношении «часть-целое».
Постоянная ссылка
* «Все объекты в языках одного уровня». Ну уж нет. Есть возможность скрывать части объекта
Вот тут наглядно видно непонимание ключевой проблемы, которую я обозначаю, и «стокгольмский синдром» от привычности к имеющимся ограниченным возможностям.
Давайте еще раз, на примере: попробуйте как срытую часть «объекта» в любом вашем любимом ЯП оформить:
— три других типа-объекта и два интерфейса, через который они взаимодействуют между собой
— в каждом из этих трех типов, внутри — еще по три типа объекта и по два интерфейса
Получается? Если да, покажите код, очень хочу взглянуть.
Удобно? Если да, покажите код, очень хочу взглянуть.
Постоянная ссылка
* «Микросервисы — усечение проблемы до головы». Я бы не стал делать столь категоричные утверждения. Микросервисы — прекрасное решение для увеличения степени масштабирования программной системы.
Микросервисы — это прекрасно не только для масшиабирования, а для много чего еще. Но проблему, которую обозначаю я («как дизайнить _один_ микросервис, если он не тривиальный, а немного покрупнее»), они сами по себе не решают, или решают так, что может стать сильно хуже по другим аспектам качества («сделайте все микросервисы настолько мелкими, чтобы программист уже совсем не мог сделать в нем кривой дизайн»).
В принципе, если у вас система хорошо раскладывается в такую мелочь, наверное это неплохой путь (и далее — в serverless). Например, если задача — массовая обработка мелких независимых событий. Но только обычно для систем работающих с более сложными структурами данных, а также — для клиентских приложений и встраиваемого софта — это точно не решение.
Постоянная ссылка
* От себя вставлю, что Клеменс Шиперски во многом задачу компонетного подхода решил вполне сносно.
К сожалению, я плохо знаком с наработками в мире Оберона и Компонентного Паскаля, глядел только по диагонали, но то, что я видел, уверяет меня в обратном. Компоненты в том смысле, в котором ввожу это понятие я, там тоже отсутствуют почти полностью, как и в остальном мире ООП — то есть они есть!, но только «одноуровневые». Отношение «часть-целое» отсутствует, удобных способов вкладывать типы и компоненты на несколько уровней — нету. Я был бы рад ошибиться в этом, и был бы признателен за пример кода, показывающий обратное.