Двач.hk прислал битые данные.
Вы видите копию треда, сохраненную 16 января 2025 года.
Можете попробовать обновить страницу, чтобы увидеть актуальную версию.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 16 января 2025 года.
Можете попробовать обновить страницу, чтобы увидеть актуальную версию.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Сап, работяги.
Как-то раз случайно наткнулся в комментариях на хуябре о том, что, мол, объектно-ориентированный уй дизайн это вторая по величине ошибка после самого ооп. И что, мол, существуют тысячи статей доказывающих это. Я прочитал, улыбнулся про себя этому старческому максимализму, да пошёл себе дальше. Но вот херня - эта мысль не дает покоя: а какие еще есть подходы в проектировании гуй-систем?
Попробую чуть разжевать. В моём понимании оо-дизайн состоит из двух черт, характерных для ооп:
1. Наследование. Общий предок <- Виджет <- Абстрактная кнопка <- Обычная кнопка
2. Агрегация. Это указатели на родительский виджет/дочерние виджеты.
Ок, единственная альтернатива, которая приходит мне в голову - декларативная парадигма. Это когда мы строим интерфейс на базе html/xml. А что еще можно противопоставить оо-дизайну?
Если не взлетит, пусть это будет обобщённый гуев-тред.
Как-то раз случайно наткнулся в комментариях на хуябре о том, что, мол, объектно-ориентированный уй дизайн это вторая по величине ошибка после самого ооп. И что, мол, существуют тысячи статей доказывающих это. Я прочитал, улыбнулся про себя этому старческому максимализму, да пошёл себе дальше. Но вот херня - эта мысль не дает покоя: а какие еще есть подходы в проектировании гуй-систем?
Попробую чуть разжевать. В моём понимании оо-дизайн состоит из двух черт, характерных для ооп:
1. Наследование. Общий предок <- Виджет <- Абстрактная кнопка <- Обычная кнопка
2. Агрегация. Это указатели на родительский виджет/дочерние виджеты.
Ок, единственная альтернатива, которая приходит мне в голову - декларативная парадигма. Это когда мы строим интерфейс на базе html/xml. А что еще можно противопоставить оо-дизайну?
Если не взлетит, пусть это будет обобщённый гуев-тред.
Этот срач стар как мир, и в этой бойне давно смешались конелюди и стерлись все границы. Даже вот ты вопрос ставишь: с чего ты взял что аггрегация это про указатели на родительский компонент? Обычно агрегацию трактуют как подход, когда ты делаешь большой компонент из ссылок на меньшие. И почему ты думаешь что аггрегация - это нечто что определяет именно ООП? В функциональной парадигме, например, есть вполне себе базированная база под названием функциональная композиция, которая в какой то мере про похожее. Или вот наследование: есть к примеру более "функциональный" термин - сабтайпинг, есть LSP когласно которому подстановка подтипов не ломает логику, базированную на базовых типах, и буквально в большинстве ООП языков обьявление наследника равноценно обьявлению подтипу (за что наследование часто и критикуют - далеко не всегда в подтип уместно наследовать все поля и методы базового типа).
Если же говорить конкретно про гуи, нагляднее всего это поле битвы просматривается во фронтенде - фронтенд прошел очень длинный путь от обоссанных страничек до электрона и прочего SPA с адаптированной версткой. Одно время фронт шел по пути ооп по лекалам какой нить условной джавы: был angularjs, который давал нотацию компонент и делал между ними dependency injection. Буквально любой спрингоеб с полпинка пересаживался на этот ангуляр - все там было просто и знакомо. За тем лишь исключением что подход - мешок хуев по сути.
Щас во фронте этот подход по большей части мертв. На смену ему пришел компонентный подход реакта, где:
- UI делится на переиспользуемые компоненты, которые обьединяют верстку, логику этой верстки и данные/биндинги под одним именем
- Малые компоненты объединяются в большие путем композиции (по типу матрешки - малые вкладываются в большие). И вот с композицией самый прикол этого месива - она имеет как черты функциональной композиции, так и черты агрегации, которую ты приписываешь ООП.
Вот и попробуй разберись во всем этом говне после этого. По сути границы между ФП и ООП давным давно стерты. Давно уже пора забить на это деление на самом деле.
Если же говорить конкретно про гуи, нагляднее всего это поле битвы просматривается во фронтенде - фронтенд прошел очень длинный путь от обоссанных страничек до электрона и прочего SPA с адаптированной версткой. Одно время фронт шел по пути ооп по лекалам какой нить условной джавы: был angularjs, который давал нотацию компонент и делал между ними dependency injection. Буквально любой спрингоеб с полпинка пересаживался на этот ангуляр - все там было просто и знакомо. За тем лишь исключением что подход - мешок хуев по сути.
Щас во фронте этот подход по большей части мертв. На смену ему пришел компонентный подход реакта, где:
- UI делится на переиспользуемые компоненты, которые обьединяют верстку, логику этой верстки и данные/биндинги под одним именем
- Малые компоненты объединяются в большие путем композиции (по типу матрешки - малые вкладываются в большие). И вот с композицией самый прикол этого месива - она имеет как черты функциональной композиции, так и черты агрегации, которую ты приписываешь ООП.
Вот и попробуй разберись во всем этом говне после этого. По сути границы между ФП и ООП давным давно стерты. Давно уже пора забить на это деление на самом деле.
Этот срач стар как мир, и в этой бойне давно смешались конелюди и стерлись все границы. Даже вот ты вопрос ставишь: с чего ты взял что аггрегация это про указатели на родительский компонент? Обычно агрегацию трактуют как подход, когда ты делаешь большой компонент из ссылок на меньшие. И почему ты думаешь что аггрегация - это нечто что определяет именно ООП? В функциональной парадигме, например, есть вполне себе базированная база под названием функциональная композиция, которая в какой то мере про похожее. Или вот наследование: есть к примеру более "функциональный" термин - сабтайпинг, есть LSP когласно которому подстановка подтипов не ломает логику, базированную на базовых типах, и буквально в большинстве ООП языков обьявление наследника равноценно обьявлению подтипу (за что наследование часто и критикуют - далеко не всегда в подтип уместно наследовать все поля и методы базового типа).
Если же говорить конкретно про гуи, нагляднее всего это поле битвы просматривается во фронтенде - фронтенд прошел очень длинный путь от обоссанных страничек до электрона и прочего SPA с адаптированной версткой. Одно время фронт шел по пути ооп по лекалам какой нить условной джавы: был angularjs, который давал нотацию компонент и делал между ними dependency injection. Буквально любой спрингоеб с полпинка пересаживался на этот ангуляр - все там было просто и знакомо. За тем лишь исключением что подход - мешок хуев по сути.
Щас во фронте этот подход по большей части мертв. На смену ему пришел компонентный подход реакта, где:
- UI делится на переиспользуемые компоненты, которые обьединяют верстку, логику этой верстки и данные/биндинги под одним именем
- Малые компоненты объединяются в большие путем композиции (по типу матрешки - малые вкладываются в большие). И вот с композицией самый прикол этого месива - она имеет как черты функциональной композиции, так и черты агрегации, которую ты приписываешь ООП.
Вот и попробуй разберись во всем этом говне после этого. По сути границы между ФП и ООП давным давно стерты. Давно уже пора забить на это деление на самом деле.
Если же говорить конкретно про гуи, нагляднее всего это поле битвы просматривается во фронтенде - фронтенд прошел очень длинный путь от обоссанных страничек до электрона и прочего SPA с адаптированной версткой. Одно время фронт шел по пути ооп по лекалам какой нить условной джавы: был angularjs, который давал нотацию компонент и делал между ними dependency injection. Буквально любой спрингоеб с полпинка пересаживался на этот ангуляр - все там было просто и знакомо. За тем лишь исключением что подход - мешок хуев по сути.
Щас во фронте этот подход по большей части мертв. На смену ему пришел компонентный подход реакта, где:
- UI делится на переиспользуемые компоненты, которые обьединяют верстку, логику этой верстки и данные/биндинги под одним именем
- Малые компоненты объединяются в большие путем композиции (по типу матрешки - малые вкладываются в большие). И вот с композицией самый прикол этого месива - она имеет как черты функциональной композиции, так и черты агрегации, которую ты приписываешь ООП.
Вот и попробуй разберись во всем этом говне после этого. По сути границы между ФП и ООП давным давно стерты. Давно уже пора забить на это деление на самом деле.
>>644
Спасибо за ответ. Если честно, я хотел, что бы мой вброс звучал максимально нейтрально и отстранённо. У меня на самом деле не так много опыта в программировании вообще, не говоря уже про десктопно-прикладное. Я начинал в турбо билдере (где в vcl композиция использовалась, но я уже и не вспомню для чего), сейчас же на моём счету целая одна утилита на кьюте. Тут, как я понимаю, агрегация используется для управления памятью, что бы при удалении родительского виджета подчищать память и за дочерними виджетами.
Моя самая, пожалуй, большая проблема - у меня нет академических знаний, потому и спрашиваю. Сейчас я, пожалуй, спать пойду, но завтра я погуглю всё то, что мне непонятно в твоём ответе.
Спасибо за ответ. Если честно, я хотел, что бы мой вброс звучал максимально нейтрально и отстранённо. У меня на самом деле не так много опыта в программировании вообще, не говоря уже про десктопно-прикладное. Я начинал в турбо билдере (где в vcl композиция использовалась, но я уже и не вспомню для чего), сейчас же на моём счету целая одна утилита на кьюте. Тут, как я понимаю, агрегация используется для управления памятью, что бы при удалении родительского виджета подчищать память и за дочерними виджетами.
Моя самая, пожалуй, большая проблема - у меня нет академических знаний, потому и спрашиваю. Сейчас я, пожалуй, спать пойду, но завтра я погуглю всё то, что мне непонятно в твоём ответе.
>>646
Ах да, я всё еще путаю композицию и агрегацию. Интуитивно понимаю разницу, но могу в письме их путать
Ах да, я всё еще путаю композицию и агрегацию. Интуитивно понимаю разницу, но могу в письме их путать
>>646
Ну а если ты новичок, возможно те вообще не стоит погружаться в этот пиздец, и не стоит пытаться щас мое полотнище парсить. Холивары в парадигмах и методологиях разработки это такой пиздец, в котором не каждый сенька то выживет и сохранит рассудок, не скатившись в каргокульт, не то что маслята. Выбери путь и пройди его до конца. Потом выбери другой путь.
Ну а если ты новичок, возможно те вообще не стоит погружаться в этот пиздец, и не стоит пытаться щас мое полотнище парсить. Холивары в парадигмах и методологиях разработки это такой пиздец, в котором не каждый сенька то выживет и сохранит рассудок, не скатившись в каргокульт, не то что маслята. Выбери путь и пройди его до конца. Потом выбери другой путь.
Двач.hk прислал битые данные.
Вы видите копию треда, сохраненную 16 января 2025 года.
Можете попробовать обновить страницу, чтобы увидеть актуальную версию.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 16 января 2025 года.
Можете попробовать обновить страницу, чтобы увидеть актуальную версию.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.