Сап, работяги. Как-то раз случайно наткнулся в комментариях на хуябре о том, что, мол, объектно-ори 3314640 В конец треда | Веб
Сап, работяги.

Как-то раз случайно наткнулся в комментариях на хуябре о том, что, мол, объектно-ориентированный уй дизайн это вторая по величине ошибка после самого ооп. И что, мол, существуют тысячи статей доказывающих это. Я прочитал, улыбнулся про себя этому старческому максимализму, да пошёл себе дальше. Но вот херня - эта мысль не дает покоя: а какие еще есть подходы в проектировании гуй-систем?

Попробую чуть разжевать. В моём понимании оо-дизайн состоит из двух черт, характерных для ооп:

1. Наследование. Общий предок <- Виджет <- Абстрактная кнопка <- Обычная кнопка
2. Агрегация. Это указатели на родительский виджет/дочерние виджеты.

Ок, единственная альтернатива, которая приходит мне в голову - декларативная парадигма. Это когда мы строим интерфейс на базе html/xml. А что еще можно противопоставить оо-дизайну?

Если не взлетит, пусть это будет обобщённый гуев-тред.
2 3314644
Этот срач стар как мир, и в этой бойне давно смешались конелюди и стерлись все границы. Даже вот ты вопрос ставишь: с чего ты взял что аггрегация это про указатели на родительский компонент? Обычно агрегацию трактуют как подход, когда ты делаешь большой компонент из ссылок на меньшие. И почему ты думаешь что аггрегация - это нечто что определяет именно ООП? В функциональной парадигме, например, есть вполне себе базированная база под названием функциональная композиция, которая в какой то мере про похожее. Или вот наследование: есть к примеру более "функциональный" термин - сабтайпинг, есть LSP когласно которому подстановка подтипов не ломает логику, базированную на базовых типах, и буквально в большинстве ООП языков обьявление наследника равноценно обьявлению подтипу (за что наследование часто и критикуют - далеко не всегда в подтип уместно наследовать все поля и методы базового типа).

Если же говорить конкретно про гуи, нагляднее всего это поле битвы просматривается во фронтенде - фронтенд прошел очень длинный путь от обоссанных страничек до электрона и прочего SPA с адаптированной версткой. Одно время фронт шел по пути ооп по лекалам какой нить условной джавы: был angularjs, который давал нотацию компонент и делал между ними dependency injection. Буквально любой спрингоеб с полпинка пересаживался на этот ангуляр - все там было просто и знакомо. За тем лишь исключением что подход - мешок хуев по сути.

Щас во фронте этот подход по большей части мертв. На смену ему пришел компонентный подход реакта, где:
- UI делится на переиспользуемые компоненты, которые обьединяют верстку, логику этой верстки и данные/биндинги под одним именем
- Малые компоненты объединяются в большие путем композиции (по типу матрешки - малые вкладываются в большие). И вот с композицией самый прикол этого месива - она имеет как черты функциональной композиции, так и черты агрегации, которую ты приписываешь ООП.

Вот и попробуй разберись во всем этом говне после этого. По сути границы между ФП и ООП давным давно стерты. Давно уже пора забить на это деление на самом деле.
2 3314644
Этот срач стар как мир, и в этой бойне давно смешались конелюди и стерлись все границы. Даже вот ты вопрос ставишь: с чего ты взял что аггрегация это про указатели на родительский компонент? Обычно агрегацию трактуют как подход, когда ты делаешь большой компонент из ссылок на меньшие. И почему ты думаешь что аггрегация - это нечто что определяет именно ООП? В функциональной парадигме, например, есть вполне себе базированная база под названием функциональная композиция, которая в какой то мере про похожее. Или вот наследование: есть к примеру более "функциональный" термин - сабтайпинг, есть LSP когласно которому подстановка подтипов не ломает логику, базированную на базовых типах, и буквально в большинстве ООП языков обьявление наследника равноценно обьявлению подтипу (за что наследование часто и критикуют - далеко не всегда в подтип уместно наследовать все поля и методы базового типа).

Если же говорить конкретно про гуи, нагляднее всего это поле битвы просматривается во фронтенде - фронтенд прошел очень длинный путь от обоссанных страничек до электрона и прочего SPA с адаптированной версткой. Одно время фронт шел по пути ооп по лекалам какой нить условной джавы: был angularjs, который давал нотацию компонент и делал между ними dependency injection. Буквально любой спрингоеб с полпинка пересаживался на этот ангуляр - все там было просто и знакомо. За тем лишь исключением что подход - мешок хуев по сути.

Щас во фронте этот подход по большей части мертв. На смену ему пришел компонентный подход реакта, где:
- UI делится на переиспользуемые компоненты, которые обьединяют верстку, логику этой верстки и данные/биндинги под одним именем
- Малые компоненты объединяются в большие путем композиции (по типу матрешки - малые вкладываются в большие). И вот с композицией самый прикол этого месива - она имеет как черты функциональной композиции, так и черты агрегации, которую ты приписываешь ООП.

Вот и попробуй разберись во всем этом говне после этого. По сути границы между ФП и ООП давным давно стерты. Давно уже пора забить на это деление на самом деле.
3 3314646
>>644
Спасибо за ответ. Если честно, я хотел, что бы мой вброс звучал максимально нейтрально и отстранённо. У меня на самом деле не так много опыта в программировании вообще, не говоря уже про десктопно-прикладное. Я начинал в турбо билдере (где в vcl композиция использовалась, но я уже и не вспомню для чего), сейчас же на моём счету целая одна утилита на кьюте. Тут, как я понимаю, агрегация используется для управления памятью, что бы при удалении родительского виджета подчищать память и за дочерними виджетами.

Моя самая, пожалуй, большая проблема - у меня нет академических знаний, потому и спрашиваю. Сейчас я, пожалуй, спать пойду, но завтра я погуглю всё то, что мне непонятно в твоём ответе.
4 3314647
>>646
Ах да, я всё еще путаю композицию и агрегацию. Интуитивно понимаю разницу, но могу в письме их путать
5 3314940
>>646
Ну а если ты новичок, возможно те вообще не стоит погружаться в этот пиздец, и не стоит пытаться щас мое полотнище парсить. Холивары в парадигмах и методологиях разработки это такой пиздец, в котором не каждый сенька то выживет и сохранит рассудок, не скатившись в каргокульт, не то что маслята. Выбери путь и пройди его до конца. Потом выбери другой путь.
Обновить тред
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски

Скачать тред только с превьюс превью и прикрепленными файлами

Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах.Подробнее