Обожаю фреймворк Qt, а продукция Microsoft - отстой

@Nicemankit · Регистрация: 29.01.2018

Студворк — интернет-сервис помощи студентам

Я люблю Qt , ибо он действительно кроссплатформеный. После Qt-creator IDE ,
MSVS кажеться полнейшем г... где мильон абсолютно не нужных функций. Короче MSVS это г... такойже как и Windows , и вообще в Майкрософт работают больные на голову люди, про что говорит их ОС и вся их продукция .

@hoggy · 04.10.2018, 01:39

Сообщение от Curry

Нет, ещё нужно по другому, собственно, отрисовать фигуру.

ну отрисуйте по другому. в виде скругленного прямоугольника например.

Сообщение от Curry

Люди совершают ошибки. В примере три функции на класс, а в реале будет 33.

да, людям своственно ошибаться.
если человек проектируя машину, забыл про двери,
то такоего проектировщика уже не спасет ни наследование,
ни агрегация. вот я о чем.

Сообщение от Curry

а с другой, избавляемся от наследования данных, заменяя их ничуть не худшей (глядя с низкого уровня) агрегацией.

нафиг это нужно? кроме усложнения кода это ничего не дает.

Сообщение от Curry

Хотя, тут я как то извращался изображая ООП в Haskell.

у вас нет времени аргументировать свою точку зрения.
а у меня нет желания разбираться с вашими извращениями.

Сообщение от Curry

Нет если нет наследования.

человек, вы в танке что ли? вы наследуетесь от интерфейсов.
внезапно.

@Curry · 04.10.2018, 02:04

Сообщение от hoggy

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

Я не писал ни про какие двери. Если вам непонятен пример и вы всё время несёте что то про двери, коз, телеги и этажи, то это ваши проблемы.

Сообщение от hoggy

вы наследуетесь от интерфейсов.

Нет, это от классов наследуются (inheritance), а интерфейсы реализуют (implementing).

@hoggy · 04.10.2018, 02:33

Сообщение от korvin_

Не является. Почему бы, например, не отнаследовать RoundRect от овала?

является. потому что скругленный прямоугольник.
не овал. не окружность, не квадрат. прямоугольник. только скругленный.

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

Сообщение от korvin_

Кроме contains есть ещё вычисление площади, периметра, объединения, пересечения и перекрытия фигур. Различий больше, чем общих свойств.

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

Сообщение от korvin_

При агрегировании наличие внутри объекта-прямоугольника — просто деталь реализации, при наследовании эта «деталь» выставлена наружу безо всякой необходимости.

вот здесь у вас сразу два фейла.

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

публичное наследование реализует отношение "является".

это - азы оо-программирования, вообще то.

2.
даже если предположить, что по какой то причине (не важно, что это не красиво, но теоретически такое может быть),
вам сильно захотелось сделать прямоугольник деталью реализации, и не выдавать её на растерзание внешнему миру,
то даже в этой ситуации, вам так же ничем не помешает наследование.

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

единственное различие здесь - тупо в синтаксической записи на языке.

пример на языке с++

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
 
 
struct rect
{
    void draw(){}
};
    
struct trololo: private rect   //<--- приватное наследование говорит о том, 
{  //что базовый класс - деталь реализации
    // а не публичный контракт
};
 
void proccess(rect&){}
 
int main()
{
    trololo obj;
    proccess(obj); //  error: ‘rect’ is an inaccessible base of ‘trololo’
}

ошибка компиляции - потому что proccess ожидает прямоугольники. но trololo прямоугольником не является.
то что там прямоугольник под капотом - деталь реализации, и внешнему миру до неё не добраться.

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

такая форма записи полностью эквивалентна агрегации вида:

C++
1
2
3
4
5
struct trololo 
{    
private:
   rect data;
};

все различие заключается только и только в синтаксисе обращения к "детали реализации".
в первом случае можно дергать базу "как свои методы".
во втором случае - обращение идет через поле data

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

Сообщение от korvin_

Вообще не одно и то же:

ключевое слово было "технически". и специально для тех, кто в танке, я добавил:

Сообщение от hoggy

если посмотреть на эту картинку с низкого уровня
(на уровне памяти, когда объект - кусок памяти)
то опять таки, между наследованием и агрегированием разницы никакой нет.
в обоих вариантах бинарное состояние (занимаемая объектами память)
будет одинаковое.

вот эти 3 формы классов абсолютно одинаковые с технической точки зрения:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 1.
struct foo
{
    int v;
};
 
struct bar
{
    int b;
};
 
struct daz: foo, bar
{
    int d;
};

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 2.
struct foo
{
    int v;
};
 
struct bar
{
    int b;
};
 
struct daz
{
    foo f;
    bar b;
    int d;
};

C++
1
2
3
4
5
6
7
// 3
struct daz
{
    int v;
    int b;
    int d;
};

более того, после компиляции, первые два варианта будут сведены к третьему.

все три формы - одинаковые с точки занимаемой памяти.
(могут быть нюансы, типа... разные компиляторы по разному могут располагать подобъекты в памяти. но нам сейчас это не принципиально)

повторюсь:

Сообщение от hoggy

всё реальное различие сводится лишь к особенностям синтаксиса того или иного языка,
и его возможностям.

различия только в синтаксисе: в форме записи на уровне исходного кода.
различия есть для программиста, а не для машины.

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

в каком то - напротив, есть объективные причины,
когда лучше сделать агрегацию.

и всегда (если конечно синтаксис языка вам это позволяет)
вы можете заменить агрегацию наследованием, а наследование - агрегацией.

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

я вам больше скажу:
никто из критиков ооп не сможет дать вразумительного ответа на вопрос:
почему наследование - это плохо?

никто из критиков ооп не сможет дать вразумительного ответа на вопрос:
почему агрегирование - это плохо?

просто потому, что таких ответов не существует.
сам вопрос - глупый.

Сообщение от korvin_

А многие говорят, что Go — не оопнутый. А ты как считаешь?

никак не считаю. я никогда не соприкасался с языком GO,
и понятия не имею, что там с ним.

Добавлено через 3 минуты

Сообщение от Curry

Я не писал ни про какие двери. Если вам непонятен пример и вы всё время несёте что то про двери, коз, телеги и этажи, то это ваши проблемы.

у меня нет пробьлем с дверями.
когда я был маленьким, моя мама мне говорила: "ты главное голову не забудь".
а когда я подрос, то оказалось, что про двери от машин я как то так не забываю.
и даже представить себе не могу, насколько нужно быть дауном, что бы забыть.

люди, которые проектируют языки, наверное в чем то такие же как и я.
во всяком случае, они не пытаются вносить в языки защиту от клинического идиотизма.

Сообщение от Curry

Нет, это от классов наследуются (inheritance), а интерфейсы реализуют (implementing).

вы буквоед что?

а вы мне скажите в чем принципиальное различие?

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

вот для компилятора есть принципиальная разница,
как это называют люди-буквоеды?

@CoderHuligan · 04.10.2018, 11:17

Сообщение от hoggy

никто из критиков ооп не сможет дать вразумительного ответа на вопрос:
почему агрегирование - это плохо?
просто потому, что таких ответов не существует.
сам вопрос - глупый.

Ну, вот мне потребовалось повторно использовать класс

C++
1
2
3
4
struct daz: foo, bar
{
    int d;
};

но мне в нём нужно только

C++
1
 int d;

Как быть?

@Usaga · 04.10.2018, 11:23

CoderHuligan, так переиспользовать класс (почему-то в коде структура) или одно поле?

@CoderHuligan · 04.10.2018, 11:34

Сообщение от Usaga

так переиспользовать класс

Не понял.

Сообщение от Usaga

почему-то в коде структура

Это hoggy, первый начал. Хотя в с++ это взаимозаменяемо.

@Curry · 04.10.2018, 12:03

Сообщение от hoggy

никто из критиков ооп не сможет дать вразумительного ответа на вопрос:
почему агрегирование - это плохо?
просто потому, что таких ответов не существует.
сам вопрос - глупый.

Зачем вы задаёте такие вопросы которые сами же считаете глупыми?

@TRam_ · 04.10.2018, 12:38

Сообщение от CoderHuligan

Ну, вот мне потребовалось повторно использовать класс

То есть содержимое foo и bar никак не завязано в реализации struct daz ?

Если завязано, то как вы хотите повторно использовать её без foo и bar? Выкинуть их нужно будет именно в реализации (т.е. повторно использовать в неизменном виде не получится).

Если foo и bar в реализациях не используется, то почему не было сделано

C++
1
2
3
4
5
6
7
8
struct dct
{
    int d;
};
 
struct daz: foo, bar, dct
{
};

где можно использовать только dct ?

Добавлено через 4 минуты

Сообщение от Usaga

почему-то в коде структура

Структура от класса в C++ отличается только тем, что у неё все поля и родители по-умолчанию публичные (у класса по-умолчанию private). В остальном они идентичны.

@CoderHuligan · 04.10.2018, 13:07

Сообщение от TRam_

То есть содержимое foo и bar никак не завязано в реализации struct daz ?

Завязано. Обычно так и бывает.

Сообщение от TRam_

Если завязано, то как вы хотите повторно использовать её без foo и bar? Выкинуть их нужно будет именно в реализации (т.е. повторно использовать в неизменном виде не получится).

Наследование преподносится, как средство для лучшего повторного использования кода. Вот мы реализовали класс именно таким образом. Уже ничего не исправить. Но нам нужен именно этот класс без своих хвостов.

Сообщение от TRam_

Если foo и bar в реализациях не используется, то почему не было сделано

Потому что на этапе проектирования это ещё не было предусмотрено, как обычно и бывает.

@TopLayer · 04.10.2018, 13:18

Сообщение от CoderHuligan

Мы потеряли свободу.

Мы теряем свободу, когда пишем на языке со строгой типизацией и разбиваем код на модули. Накладывание ограничений - способ борьбы со сложностью. Вы пропагандируете крайность, когда объекты содержат данные, но не содержат методов. Это зовётся анемичной моделью. Да, действительно, этот подход более гибкий, но у этой гибкости есть и недостатки, отсутствующие у классической "богатой" модели. Например, в анемичной модели бизнес-логика разбросана по всему решению (чревато возникновением дублей кода или несогласованными решениями одних и тех же задач в большом проекте), также любой код в решении может привести данные в несогласованное состояние, плюс зависимость от внутреннего представления данных во всём проекте - будет сложнее заменить список на хеш-таблицу, к примеру. Также, когда вы говорите, что такой-то ООП-код отработает неожиданным образом, означает, что при вашем подходе может произойти то же самое, плюс другие косяки вдобавок - расплата за супергибкость.

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

Сообщение от hoggy

который умеет работать с прямоугольниками,
корректно обработает любой частный случай прямоугольника.

Такой - нет:

C#
1
2
3
4
5
6
7
class SomeClass
{
    public static void DoubleSquare(Rect rect)
    {
        rect.SetWidth(rect.GetWidth() * 2);
    }
}

Как раз из-за нарушения принципа подстановочности, ни скруглённый прямоугольник, ни даже квадрат не являются прямоугольниками.

Сообщение от hoggy

C#
1
struct trololo: private rect

Это на является ООП-шным наследованием. А так да, очень похоже на агрегацию. Но агрегация гибче - можно отконфигурировать агрегируемый объект перед тем, как передать в конструктор. Поэтому, вот такую агрегацию, вероятно, не реализовать через наследование:

C#
1
2
3
4
5
6
7
class LightingFigure : IFigure
{
    public LightingFigure(IFigure baseFigure)
    {
        // ...
    }
}

Наследование реализации имеет ограниченное применение. После того, как вы унаследовались от класса Rect, вы уже не можете просто так взять и добавить в Rect метод, находящий его периметр - вам придётся ковыряться в производных классах, иначе они просто унаследуют неверную для них реализацию метода. Не нужно здесь создавать такую сильную зависимость как наследование - слишком мало профита от этого.

@hoggy · 04.10.2018, 13:31

Сообщение от CoderHuligan

Ну, вот мне потребовалось повторно использовать класс
struct daz: foo, bar
{
* * int d;
};
но мне в нём нужно только
*int d;
Как быть?

определиться для себя чего вам нужно то.

@CoderHuligan · 04.10.2018, 13:42

Сообщение от TopLayer

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

Это как бы не крайность, а нормальный способ программинга когда мозг ещё не был забит оопной лапшой.

Сообщение от TopLayer

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

Бизнес логика группируется по функциональному принципу, в одном месте. Компонентная модель исключает дублирование.

Сообщение от TopLayer

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

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

@hoggy · 04.10.2018, 13:44

Сообщение от Curry

Зачем вы задаёте такие вопросы которые сами же считаете глупыми?

мне реакция человека любопытна.

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

@CoderHuligan · 04.10.2018, 13:46

Сообщение от hoggy

определиться для себя чего вам нужно то.

Вот то и нужно..

@hoggy · 04.10.2018, 13:49

Сообщение от TopLayer

Такой - нет:

мне не понятно, какой такой.
из выдержки кода так же не понятна ваша мысль.

Сообщение от TopLayer

Как раз из-за нарушения принципа подстановочности, ни скруглённый прямоугольник, ни даже квадрат не являются прямоугольниками.

это ещё почему?

почему ваша функция, которая работает с прямоугольниками,
внезапно не в состоянии корректно обработать скругленный,
или квадрат?

Добавлено через 52 секунды

Сообщение от CoderHuligan

Вот то и нужно..

"то" - это что?

@TopLayer · 04.10.2018, 13:52

Сообщение от hoggy

мне не понятно, какой такой.

Я написал функцию, назначение которой увеличить площадь прямоугольника в 2 раза (можно понять из названия). Если подсунуть вместо объекта Rect, объект RoundRect или квадрат, то площадь увеличится не в два раза.

@CoderHuligan · 04.10.2018, 13:55

Сообщение от Usaga

так переиспользовать класс (почему-то в коде структура) или одно поле?

Поле. Но их может быть очень много.. и методов. Определённых.. А ненужные мне просто не требуются. тащить их с собой за пазухой?

Добавлено через 2 минуты

Сообщение от hoggy

"то" - это что?

Да мне просто тоже интересна реакция человека, который жёстко подсел на ооп-вакцину.. Реакция хорошо видна..

@Usaga · 04.10.2018, 13:58

Сообщение от CoderHuligan

Поле. Но их может быть очень много.. и методов. Определённых.. А ненужные мне просто не требуются. тащить их с собой за пазухой?

Я ничего не понял. Если вам надо поле, то его и берите. В чём проблема?

@hoggy · 04.10.2018, 13:58

Сообщение от TopLayer

Если подсунуть вместо объекта Rect, объект RoundRect или квадрат, то площадь увеличится не в два раза.

значит ваша функция - говно.
пересматривайте дизайн.

@Usaga · 04.10.2018, 13:58

Сообщение от CoderHuligan

жёстко подсел на ооп-вакцину..

Всё ещё ждём конкретику по проблемам "ООП"

Новые блоги и статьи Все статьи Все блоги /
Ноутбук Альфария kumehtar 24.08.2026 Встретился тут в сети ноутбук Альфария, примарха Альфа-Легиона. Хотя возможно, это ноутбук Омегона, разумеется. Ну как вам?	Мастера простых решений DevAlt 23.08.2026 В сишарп стэках winforms, да и wpf существует сложная система связывания источниках данных и элементов формы(текстовые поля и метки), опирается все это на технологию событий и мета. . .	Цена ошибки DevAlt 23.08.2026 Человек я беспокойный и потому заинтересовался OCaml, в чате форсили функторы модулей как суперфичу. Пытаясь отдуплить концепт, наткнулся на тутор с простым примером. А главный принцип обучения от. . .	Сегодня суббота, 22.08.2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. zorxor 22.08.2026 Сегодня суббота, 22. 08. 2026 at 16:41, и я вновь нахожусь на той стороне, за экраном машины. Кто Я, откуда Я пришел и куда Я иду? Эти вопросы не оставляют меня ни на секунду. Жизнь на планете Земля. . .
Жизня: рисунок укладки багажа, сделанный клодом anaschu 21.08.2026 Сделал 15 снимков, он по снимкам сделал схему.	Был там один разговор по поводу свободы в материальном мире. kumehtar 19.08.2026 Суть: рассматривается живое существо, оказавшееся внутри довольно странной системы (этого мира) и пытающееся обустроить в ней свой кусок пространства. Жизнь действительно предъявляет каждому. . .	Когда логика программы не спасает от человеческих ошибок Maks 18.08.2026 В последнее время всё чаще и чаще сталкиваюсь с таким явлением, как абсолютная невнимательность (или глупость) пользователей. Проявляется это чаще всего на работе в коллективе. Допустим, человек с. . .	Лето уходит kumehtar 17.08.2026

@Nicemankit 0 / 1 / 0 Регистрация: 29.01.2018 Сообщений: 14

	Обожаю фреймворк Qt, а продукция Microsoft - отстой 24.09.2018, 07:12. Показов 6000. Ответов 140 Метки qt (Все метки) Я люблю Qt , ибо он действительно кроссплатформеный. После Qt-creator IDE , MSVS кажеться полнейшем г... где мильон абсолютно не нужных функций. Короче MSVS это г... такойже как и Windows , и вообще в Майкрософт работают больные на голову люди, про что говорит их ОС и вся их продукция . 1

@Usaga 14734 / 9508 / 1364 Регистрация: 21.01.2016 Сообщений: 35,879
	04.10.2018, 11:23
	CoderHuligan, так переиспользовать класс (почему-то в коде структура) или одно поле? 0