Стоит ли использовать ООП?

@@KOT@ · Регистрация: 29.01.2010

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

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

@Fulcrum_013 · 11.09.2017, 16:03

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

Мистеру Дейкстре(всё-таки гениальный был человек!) достаточно опредилить те состояния, в которых может находится тот или иной обьект,

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

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

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

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

Что именно вы называете модульным подходом? Единица трансляции (unit) модулем (module) в общетехническом смысле слова не является. Если во времена совдепии невежды-академики этого не поняли в виду незнания человеческих языков, то это проблема совдеповского наречия.

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

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

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

А соответсвенно вы потеряли динамический полиморфизм как минимум. Для полиморфизма должна быть гарантия соответствия общему интерфейсу. Как вы это будете гарантировать в вашей копи-паст каше?

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

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

Мы рассказываем браузеру как должен выглядеть документ

Дык по декларациям евангелистов декларативщиков командовать как что то делать - это прерогатива каменного имперетивщиного каменного топора, а труе декларативщина только декларирует что делать? Дык может таки противопоставлять декларативно/императивнно это есмь сапоги в смятка однако?

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

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

Всё то же самое, только без эфемерных коней в компиляторе.

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

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

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

А любой язык описывает проблему и даёт инструкции,

Нет. Язык описания данных описывает данные и не более.

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

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

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

В теории может быть. На практике получаем жопу под названием комбинаторный взрыв состояний. При этом добавить в потомка состояние которого нет у предка будет тот еще гемморой.

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

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

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

В теории может быть. На практике получаем жопу под названием комбинаторный взрыв состояний. При этом добавить в потомка состояние которого нет у предка будет тот еще гемморой. Кстати так о птичках автомат равноценный паре автоматов будет иметь n*m состояний в то время как пара автоматов n+m. Я так подозреваю Дейкстра имел в виду кое что другое. к примеру свойство Allign действительно лучше задать энумом

C++
1
enum TAllign{alNone,alLeft,alRight,alTop,alBottom,alClient};

, потому что в любой момент времени объект может находится только в одном из этих состояний. Но к примеру оно никак не связано с состоянием ReadOnly.
Это фактическки разные механизмы действующие праллельно. Т.е.

C++
1
TState{stNoneEnabled,stLeftEnabled,stRightEnabled,stTopEnabled,stBottomEnabled,stClientEnabled,stNoneDisabled,stLeftDisabled,stRightDisabled,stTopDisabled,stBottomDisabled,stClientDisabled}

как вы предлагаете делать это уже из области маразма. Попробуйте добавить сюда еще DragMode который имет 3 варианта - dmNone dmAuto и dmManual а так же еще кучу переключателей типа DockSite (может или не может доковать другие контролы) AllowUndock (разрешено или нет отстыковываться от предка) и т.д. - получите полную жопу которую вы предлагаете скопировать 1000 раз вручную.

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

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

Так все механизмы остаются в нашем распоряжении.

А при использовании наследовании они тоже никуда не деваются. При этом еще и префиксы разгадывать не надо их компилятор разгадает. НУ еще и куча копипаста не нужна. Т.е. то что вы предлагаете - это то что делали программисты в 60-х 70-х пока к примеру Страуструпу это не надоело и он не обучил этому машину на качественно гораздо более высоком уровне (хотя способ как это делать был уже известен со времен Симулы).

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

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

Традиционный код в своём составе имеет множество флагов-переменных,

Вы бы прежде чем Дейкстру цитировать посмотрели бы на то что он подразумевал (вернее то что в его времена являлось) традиционным кодом. Современный код ушел гораздо дальше чем то о чем говорит Дейкстра. Причем его рекомендации естественно применяются для мелких деталей. НО это абсолютно не значит что то что применимо к отдельно взятому мелкому винтику применимо и к гигантской сборке в целом.

@CoderHuligan · 11.09.2017, 16:29

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

Не получится от них избавится. Они работают параллельно. т.е. объект может быть одновременно как видим так и включен в очередь получения фокуса и т.д.

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

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

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

Простая кнопка имеет всего два состояния: нажата, отжата.

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

Что именно вы называете модульным подходом? Единица трансляции (unit) модулем (module) в общетехническом смысле слова не является.

Пока я веду речь о том модуле, что существует в языке си, то есть просто отдельном файле или группе таких файлов.
Это в виртовском Обероне модуль является единицей компиляции.

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

А соответсвенно вы потеряли динамический полиморфизм как минимум. Для полиморфизма должна быть гарантия соответствия общему интерфейсу. Как вы это будете гарантировать в вашей копи-паст каше?

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

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

Кстати так о птичках автомат равноценный паре автоматов будет иметь n*m состояний в то время как пара автоматов n+m.

Теоритически. Практически мы используем только ограниченное их количество, нужное нам по смыслу задачи. Ненужные мы просто отбрасываем.

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

как вы предлагаете делать это уже из области маразма.

Опять вы путаете события и состояния.

@Fulcrum_013 · 11.09.2017, 16:29

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

Так все механизмы остаются в нашем распоряжении.

Нет. Потому что равноценна и является это разные отношения.
К примеру

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Base{
   int Value;
}
struct Child{
   int Value;   
   int Value2;
};
void AddValue(Base& L, int R){L.Value+=R;}
int main(){
  Base B;
  Child C;
  AddValue(B,5); //Ок
  AddValue(С,5);// ошибка, потому что Сhild не является Base, хотя и равноценен ему; 
};

а если сделать вот так

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
struct Base{
         int Value;
};
struct Child:public Base{
       int Value2;
};
void AddValue(Base& L, int R){L.Value+R;}
int Main(){
  Base B;
  Child C;
  AddValue(B,5); //Ок
  AddValue(С,5)+=5;// все тоже ок потому что Child является Base;   
};

Вот по этому и говорится что ООП позволяет повторное использование кота в отличии от процедурщины. Т.е. в том что предлагаете вы кот умеет ловить только одну мышь. Если мышь родила мышенка придется рожать для него другого кота. С использованием наследования кот будет ловить мышь и любого из ее потомков.

@CoderHuligan · 11.09.2017, 16:44

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

это значит у вас отсутствует повторное использование кода функций у схожих типов.

Почему это? У нас свобода..

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

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

Никакой проблемы. Функция-автомат имеет всего одну переменную состояния. Код разных состояний независим друг от друга, т.е. в каждое из них можно попасть независимо от других. Если мне потребуется добавить ещё несколько, то я их просто добавлю НЕ ТРОГАЯ другие.

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

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

void AddValue(Base& L, int R){L.Value+R;}

Что реально в плюсах можно так во втором вызове функции AddValue? А не так?:

C
1
void AddValue(Base& L, int R){L.Value2+R;}

То бишь нужна ДРУГАЯ функция? Поля ведь разные.

@Fulcrum_013 · 11.09.2017, 17:15

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

То бишь нужна ДРУГАЯ функция? Поля ведь разные.

там += должно быть. Главное что есть поле с которым работает функция. А то что там есть еще что то кроме этого - не ее забота. Оно к ее задаче отношения не имеет. т.е. к примеру есть сущность животное. Оно по определению умеет срать. Есть два подтипа животных к примеру пауки и позвоночнные ну и далее по дереву дарвина. Так вот функции "срать" сугубо перпендикулярно имеет ли это животное позвоночник и ли у него 8 глаз или два. И даже сугубо фиолетово чем оно на досуге занимается - паутину плетет, мед собирает или говнокодит. ПОэтому эту функцию можно написать один раз для любого животного. но при этом и паук и пчела и говнокодер должны являться животными а не просто содержать эквивалентный набор полей

Добавлено через 3 минуты
Именно поэтому при использовании наследования избегаются ненужные связи между различными механизмами присущими одной конкретной сущности. С вашим же подходом получается что функция срать зависит как от наличия у животного позвоночника так и количества глаз и занятий на досуге и т.д. и т.п.

@CoderHuligan · 11.09.2017, 17:21

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

Оно к ее задаче отношения не имеет.

А как же обработать поле Value2 в Child? Всё равно вам придётся переопределять эту функцию, то есть фактически её писать заново. А?

@Fulcrum_013 · 11.09.2017, 17:38

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

Всё равно вам придётся переопределять эту функцию, то есть фактически её писать заново. А?

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

@CoderHuligan · 11.09.2017, 17:54

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

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct Base{
   int Value;
}
struct Child{   
   int Value2;
};
void AddValue_Base(Base& L, int R){L.Value+=R;}
void AddValue_Child(Child& L, int R){L.Value2+=R;}
int main(){
  Base B;
  Child C;
  AddValue_Base(B,5); //Ок
  AddValue_Child(С,5);// как видно тут понятно что к чему относится; 
};

@Fulcrum_013 · 11.09.2017, 19:13

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

// как видно тут понятно что к чему относится

Только механизм присутствующий в предке у вас в потомке где то потерялся.
т.е. AddValue_Base(Child,5); вы сделать не сможете. А именно это нужно чтобы кот ловил не только мышь но и ее потомков.

Добавлено через 28 минут
Value2 предназначено для какого то более другого механизма чем Value. При этом вам придется переписать механизм работающий с Value заново.
Т.е. будет:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
struct Base{
   int Value;
}
struct Child{   
   int Value2;
};
void AddValue_Base(Base& L, int R){L.Value+=R;}
void AddValue_Child(Child& L, int R){L.Value+=R;}
void OtherTask_Child(Child& L,OtherArgs...){// делаем что то c Value2;}
int main(){
  Base B;
  Child C;
  AddValue_Base(B,5); //Ок
  AddValue_Child(С,5);// как видно тут понятно что к чему относится; 
};

А теперь представьте что количество возможных потомков Base бесконечно. Следовательно вам придется сделать бесконечное множество копий AddValue_Base по одной для каждого из потомков. При использовании наследования достаточно одного метода AddValue у Base. при этом придется постоянно смотреть какого именно типа потомок чтобы вызвать для него AddValue, при наследовании этого делать не надо. Вся фишка в том что для того чтобы пользовать одного кота для всех потомков необходимо отличать эквивалентынх от являющихся. Разница в том что эквивалентные наборы не обязательно являются потомками друг друга. т.е. к примеру вектор в унифом пространстве и кватернион абсолютно разные сущности хотя и имеют одинаковую сигнатуру полей. А вот является подразумевает эквивалентен. Поэтому и необходимо наследование - это фактически расстановка пометок кто кем является. Ну а поскольку является подразумевает эквивалентность то и эквивалентность эту необходимо обеспечивать автоматически. А что касается типа не удобно описание - ну во первых гораздо удобннее конда весь механизм один раз находится в одном месте, чем бесконечное множество его копий размазанных по коду. Во вторых выделенные механизмы предков присутствуют у всех потомков без изменения. В результате к примеру в наборе из 1000 типов контролов вся общая для них часть помещается в десяток общих механизмов обеспечивающих фактически взаимодействие оных контролов с единой инфраструктурой, а сами контролы отличаются только своими конкретными задачами. т.е. по большому счету достаточно посмотреть как работает механизм предков у одного контрола чтобы знать как он работает у всей тысячи. Это гораздо удобнее чем 1000 разных описаний размазанных по всему коду.

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

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

Опять вы путаете события и состояния.

Это вы по всей видимости путаете события и состояния. Allign это многонозиционный переключатель переключающий каким образом контрол выравнивается относительно родительского (в дереве отрисовки) контрола. А ReadOnly - это тумблер включающий/выключающий возможность пользовательского ввода в контрол. т.е. и то и другое состояния

@TRam_ · 11.09.2017, 19:29

Предлагаю такой вариант:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
struct Base
{
   int Value;
   Base() : Value(0) {}
};
 
struct Child : public Base
{   
   int Value2;
   Child() : Base(), Value2(0) {}
};
 
void AddValue(Base& L, int R){L.Value+=R;}
void AddValue(Child& L, int R){L.Value2+=R;}
 
int main()
{
  Base B;
  Child C;
  AddValue(B,5);        // вызов AddValue(Base& L, int R)
  AddValue(C,5);        // вызов AddValue(Child& L, int R)
  AddValue(static_cast<Base &>(C),5);   // вызов AddValue(Base& L, int R) для Child
}

Добавлено через 4 минуты
Который в полностью ООП-стиле выглядел бы так:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
struct Base
{
   int Value;
   Base() : Value(0) {}
   void AddValue(int R){Value+=R;}
};
 
struct Child : public Base
{   
   int Value2;
   Child() : Base(), Value2(0) {}
   void AddValue(int R){Value2+=R;}
};
 
int main()
{
  Base B;
  Child C;
  B.AddValue(5);        // вызов AddValue(Base& L, int R)
  C.AddValue(5);        // вызов AddValue(Child& L, int R)
  C.Base::AddValue(5);  // вызов AddValue(Base& L, int R) для Child
}

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

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

C++
1
2
3
4
5
6
struct Base{
   int Value;
}
struct Child{   
   int Value2;
};

речь о случае, когда

C++
1
2
3
4
struct Child{   
   int Value;
   int Value2;
};

@Fulcrum_013 · 12.09.2017, 02:37

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

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

А в С тоже модулей как таковых нет. Есть единицы трансляции. В общетехническом плане модулем является именно класс.

@CoderHuligan · 12.09.2017, 20:38

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

Это вы по всей видимости путаете события и состояния. Allign это многонозиционный переключатель переключающий каким образом контрол выравнивается относительно родительского (в дереве отрисовки) контрола. А ReadOnly - это тумблер включающий/выключающий возможность пользовательского ввода в контрол. т.е. и то и другое состояния

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

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

А теперь представьте что количество возможных потомков Base бесконечно. Следовательно вам придется сделать бесконечное множество копий AddValue_Base по одной для каждого из потомков.

У меня Base может быть обьявлено в другом файле. Здесь он просто создаётся и добавляет недостающие определения типов. Мне не надо ничего ни у кого наследовать, вот в чём дело. Я просто пользуюсь этим. И ничего не надо копировать, тем более функции, это бред. Есть одна функция, которая используется всеми экземплярами.
Если честно, то я бы даже не стал пользоваться этими определениями из других файлов, а создавал бы обьекты в свои файлах с нуля. Это не увеличит исполняемый код, а только увеличит листинг программы, одноврменно повысив её поддержку. Если разрабатывается некая игра, то там может быть множество обьектов-акторов. Каждый такой тип обьекта будет иметь своё собственное описание в соответствующем файле-модуле. Если мне будет нужно изменить его описание и поведение, то я его изменю не трогая определения других обьектов в других файлах. От слова "совсем". Нет тут никакой связности между типами. Между функциями-контролёрами может быть.

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

А в С тоже модулей как таковых нет.

И можно эмулировать.

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

речь о случае, когда

Так я уже добавил переменную Value в структуре Base. Мне не нужно определять другую структуру и наследовать..

@Fulcrum_013 · 12.09.2017, 22:21

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

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

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

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

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

Так я уже добавил переменную Value в структуре Base. Мне не нужно определять другую структуру и наследовать..

Вообще то разговор шел о расширении набора данных и поведения сущности а не о создании абсолютно невзаимосвязанных наборов. Т.е. Child должен помнить/уметь делать все что и Base плюс еще что то.

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

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

И ничего не надо копировать, тем более функции, это бред.

Как вы обеспечите наличие функционала/данных Base у Child?

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

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

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

Для того чтобы ничего не менять в других файлах нужен полиморфизм который вы во всю стараетесь похерить. У вас сущности живут в сферическом вакууме. В реальности они живут в какой либо инфраструктуре. Если попытаетесь добавить сущность без полиморфизма то придется как всю инфраструктуру перекроить так и для сущности написать механизмы взаимодействия с инфраструктурой. Т.е. с таким подходом у вса не только 1000 копий одного и того же будет но и кот того с чем оно взаимодействует в 1000 раз больше.

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

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

И можно эмулировать.

Еще раз говорю - не путайте единицу трансляции и модуль. Паскалевский юнит модулем в общем случае не является, поскольку не может иметь инстансов. В общетехническом понимании слова модуль (module) таковым является класс но никак не единица трансляции (unit)

@CoderHuligan · 13.09.2017, 18:28

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

Вообще то разговор шел о расширении набора данных и поведения сущности а не о создании абсолютно невзаимосвязанных наборов. Т.е. Child должен помнить/уметь делать все что и Base плюс еще что то.

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

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
typedef struct Base
{
    int Value;
}Base;
 
typedef struct Base* NewBase;
 
typedef void (*AddValue_BaseAdr)(NewBase, int);
 
typedef struct Child
{
    NewBase B;
    AddValue_BaseAdr func_Base;
    int Value2;
}Child;//наследник
 
typedef struct Child* NewChild;
 
void AddValue_Base(NewBase L, int R){L->Value+=R;}
 
void AddValue_Child(Child* L, int R)
{
    L->func_Base( L->B, R);
    L->Value2+=R;
}

И так далее без всякого ООП.
А у вас одни классы объектов переплетаются с другими.
Да и свойство ООП-объектов обмениваться сообщениями как-то не вяжется со сложившейся практикой смешивать процедурный подход с объектным. При этом получается большая связность обьектов с друг другом. То есть ваш код это та же процедурщина приправленная лапшой наследственности. Лапша в лапше.. Кстати идея обмена сообщениями в общем смысле есть довольно прогрессивная идея.
В чём вообще заключается смысл обмена сообщениями?
Когда люди общаются между собой, таким образом передавая информацию друг-другу, они не лезут сразу в черепушку своих визави, имея информацию об устройстве этой черепушки, но используют посредника в виде воздушной среды, при помощи которой звуковые волны распространяются от одного источника к другому получателю и наоборот. То бишь, нужен некий интерфейс или посредник. Это первое.
Второе заключается в том, что людям нужен некий язык взаимного общения, который могли бы понимать оба участника. Короче говоря нужен некий лексикон.
Должны иметь место два необходимых фактора.
Например в win api есть некий лексикон сообщений, который ОС посылает приложению начинающихся с префикса WM(Window Messige). ОС ничего не знает о нашем приложении, она только информирует его о произошедшем событии. Почему бы обьектам не поступать так же?

@Fulcrum_013 · 13.09.2017, 19:48

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

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

Вот именно эти мозговыносящие костыли Страуструп и порезал заменив гораздо более удобным (а соответсвенно более читабельным и писабельным) механизмом который при этом граздо более эффективен, так как вызова методов предка всегда статические и во многих случаях инлайнятся.

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

А у вас одни классы объектов переплетаются с другими.

Наследование нужно не для взаимодействия предка с потомком, а для отделения от конкретного потомка какого либо механизма работающего одинаково для всех потомков.
пример иерархии VCL во главе TObject. Он умеет найти в RTTI методы/поля по имени и имена по адресам методов/полей. И больше в общем то ничего.
От него унаследован TPresistent. Он умеет писаться/читаться в специальный поток.
От него унаследован TComponent - он обеспечивает механнизм слежения за жизненным циклом компонентов.
Дальше начинается ветвление. от TComponent поражден TControl, TMenu и все невизуальные компоненты. TControl умеет поменять размеры/выравняться иметь дочерние контролы и самому детем быть. TMenu умеет обрабатывать виндвское древовидное меню. невизуальные компоненты умеют кому что нужно. от TControl порожден TWinControl который умеет обрабатывать окно WinAPI и TGraphicControl который представляет собой компонент рисуемый не как стандартный контрол WinAPI. а вот от этих двух гавриков порождено все визуальное. При этом вызовов методов предка из своего метода почти нет. Т.е. - каждый из потомков просто добавляет свой механизм к уже существующему. В результате мы можем принять на вход/поместить в список только тех кто имеет определенный механизм даже если они разных типов и обработать их одним и тем же котом.

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

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

То есть ваш код это та же процедурщина приправленная лапшой наследственности.

Нет. Это отправка сообщений другим объектам.

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

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

Например в win api есть некий лексикон сообщений, который ОС посылает приложению начинающихся с префикса WM(Window Messige).

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

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

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

огда люди общаются между собой, таким образом передавая информацию друг-другу,

А когда человек думает? Ну типа когда весь процесс происходит в одном ~~черепной коробке~~ адресном пространстве? Вы когда в шахматы играете наверное же моделируете взаимодействия объектов на доске? Но для этого воздух сотрясать словесами не нужно. У человека две сигнальных системы - первичная чтобы думать и используется она исключительно думалкой исключительно в своем черепушке и вторичная чтобы с другими думалками в других черепушках сообщениями обмениваться. Чем программы хуже?

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

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

А у вас одни классы объектов переплетаются с другими.

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

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

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

Кстати идея обмена сообщениями в общем смысле есть довольно прогрессивная идея.

Только методы деспетчирезации бывают разные.

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

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

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

Вот таким языком и есть интерфейс класса.

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

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

То есть ваш код это та же процедурщина приправленная лапшой наследственности. Лапша в лапше..

Нет. Это процедурщина с отсортированной лапшей. Каждая спагетина аккуратно упакована в свой кулечек с нанесенных QR-кодом и помещена на свою полочку

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

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

имея информацию об устройстве этой черепушки

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

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

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

И так далее без всякого ООП.

Без ООП не получится. А без ООП классово-ориентированного стиля - это костыленье классово-ориентированного стиля вручную. Потому что классово-ориентированный стиль создан специально для автоматического обеспечения принципов SOLID и прочих правил ООП парадигмы.

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

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

А у вас одни классы объектов переплетаются с другими.

Переплетаются и знают интерфейс других классов - это две огромные разницы.

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

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

Лапша в лапше..

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

@CoderHuligan · 14.09.2017, 18:30

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

пример иерархии VCL во главе TObject

TObject можно использовать напрямую, как абстрактный общий тип данных? Нельзя, ибо он ничего из себя не представляет. Почему-то в ООП обычно начинают с наиболее абстрактных сущностей.. Но последовательно спускаясь по иерархическому древу потомков, эти оные потомки попутно наследуют совершенно ненужные им типы. Расчёт на то, что им когда-нибудь что-то понадобится, и для этого нужно иметь потенциально всё древо возможностей, это попросту глупая идея. Выходит, что чем абстрактней сущность, тем меньше у неё возможностей? А чем ограниченнее сущность, тем больше у неё возможностей? Но это же абсурд! Имеем класс "Фигуры", и его потомков "Квадрат", "Треугольник", "Круг" и т.п. Затем нам надо в вести класс "Точка" и класс "Линия". Линия и точка не являются фигурами. Фигуры состоят из линий и точек. Где их разместить в дереве классов? Если идти от общего к частному, то они должны быть наследниками конкретных фигур. Предположим что через пень-колоду мы этого добились. Теперь точка и линия стали потенциальными наследниками общего класса "фигуры" Пешка стала королевой, а королева пешкой!
Не кажется ли вам, что всё должно быть несколько наоборот?
Начинать нужно с точки, продолжать линией, заканчивать фигурами... Если уж заниматься этим самым наследованием..

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

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

Алан Кей, один из создателей языка Smalltalk, как-то заметил, что создавая ООП они не имели в виду С++. По всей видимости из-за прямого вызова методов и наличия в коде низкоуровневых средств типа указателей. О том, что прямой вызов методов в ООП небезопасен из-за возможного зацикливания и исчерпания стека, я уже говорил.
В рамках одного адресного пространства можно вводить псевдопараллельность. Да и писать приложения и системы последовательного исполнения сейчас уже не модно и просто опасно, ибо сбой в одном компоненте остановит всю программу, поэтому от структурной разработки и отказались в пользу некоего парралельного существования оьектов.
В программе может быть много уровней контекстов. В каждом из них ограниченное количество обьектов, параллельное существование которых можно обеспечить. Да и при традиционной разработке можно использовать отдельного диспетчера-почтальёна, который бы являлся посредником между отдельными компонентами системы.
Скажите пожалуйста где у вас ООП? Да его, настоящего ООП просто нет. Нет настоящей посылки сообщений, как нет настоящего наследования.

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

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

То что там обьект думает это его собственное дело. Главное, что он при этом выносит на поверхность..
От этого зависит реакция других обьектов. Другие обьекты ничего не знают о его мыслительных способностях. Они судят уже "по факту".
Некие обьекты отдают приказы. Некие обьекты их получают и выдают "на гора" сообщения о том, что приказ выполнен. Должна быть иерархия типа - приказчик-исполнитель. Исполнители, при определённых обстоятельствах сами могут отдавать приказы своим собственным "рабам"..

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

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

Нужно знать его ЛЕКСИКОН или ЯЗЫК "межнационального общения".

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

Мало того, компилятор гарантирует что

А я бы не полагался во сём на этот вездесущий компилятор..

Добавлено через 10 минут
Одно из определений ООП гласит, что каждый обьект имеет своё собственное состояние. А это значит, что он должен создаваться, как конечный автомат. То есть: у вас нет ни настоящего наследования, ни настоящего обмена сообщениями, ни контроля над состоянием обьектов.
Так где же тогда ваше ООП?

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

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

Этот способ нужен для общения программ живущих в разных адресных пространствах.

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

@Fulcrum_013 · 15.09.2017, 01:02

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

потому что один обьект будет знать внутреннее устройство других методов.

Он должен знать список методов но не их внутреннее устройство.

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

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

А это значит, что он должен создаваться, как конечный автомат

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

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

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

Алан Кей, один из создателей языка Smalltalk, как-то заметил, что создавая ООП они не имели в виду С++.

И в результате создал юселесс фигню моментально оказавшуюся на свалке истории.

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

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

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

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

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

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

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

Состояние - это совокупность полей объекта.

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

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

Нужно знать его ЛЕКСИКОН или ЯЗЫК "межнационального общения".

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

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

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

Исполнители, при определённых обстоятельствах сами могут отдавать приказы своим собственным "рабам"..

Не путайте иерархию объектов и иерархию классов. Это две огромные разницы.

Добавлено через 1 час 27 минут

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

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

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

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

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

А я бы не полагался во сём на этот вездесущий компилятор..

НУ в конкретно в этом вопросе полагаться нельзя на человека.

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

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

А если нам потребуется изменить сами параметры и их количество, то придётся менять код в других классах, которые пользуют эту бедную функцию.

ООП-ники сначала думают а потом уже код пишут. Кстати такую же привычку стоило бы завести и говнокодерам от других парадигм. Тогда и менять нужно гораздо меньше. А особенно сигнатуры методов. Вот блин не помню вообще чтобы сигнатуры методов менять приходилось при расширении.

@CoderHuligan · 15.09.2017, 19:28

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

На самом деле как бесконечнная машина состояний.

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

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

И в результате создал юселесс фигню

Вполне работоспособную.

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

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

Но её возможность может быть сведена к минимуму по тому же Тьюрингу.

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

Состояние - это совокупность полей объекта.

Совокупность полей обьекта это его контекст. А состояние это параметр абстрактного алгоритма, а не конкретных полей.

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

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

Собака обязана знать только то, что ей полагается. У вас собака потенциально академик.. А это ей нужно? Нет, как пятая нога собаке.

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

ООП-ники сначала думают а потом уже код пишут.

Знаете такого оопника как Скотт Майерс https://ru.wikipedia.org/wiki/Майерс,_Скотт? Он написал несколько книг по с++, одна из которых "Эффективное использование С++". Кажется что более опытного оопника трудно отыскать. Однако он написал статью "Когда приходится инкапсулировать, то иногда лучше меньше, чем больше." http://www.softcraft.ru/coding/sm/, в которой доказывает, что инкапсуляция методов тем больше, чем меньше методов находится в классе и чем больше их вынесено за класс.
Многие уважаемые оопники уже давно твердят о вреде наследования. Теперь хорошо виден вред и от связывания процедур и данных в одной общей клетке...
Итак, ООП сдаёт свои позиции одна за другой. Практически от него уже ничего не осталось..

Функциональное программирование поставило во главу угла функцию.
Обьектно-ориентированное программирование поставило во главу угла данные.
Между этими двумя противоположенными крайностями должна быть некая золотая середина.
Вам так не кажется?..

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

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

пример иерархии VCL во главе TObject

Если есть иерархия, то должна быть связь между сущностями по иерархическому принципу распределения ответственностей. В дереве классов ООП такой ответственности не прослеживается, там всё плоско и перемешано - и это именуется иерархией!

@Shamil1 · 15.09.2017, 23:22

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

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

В смысле - меньше двух?

@Fulcrum_013 · 16.09.2017, 03:19

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

Конечный автомат, по определению имеет конечное число состояний.

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

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

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

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

Вот о чем и говорится как о главном преимуществе ООП. Все четко разграничено по зонам ответственности. У каждого класса своя зона. В данном конкретном случае с VCL зона ответственности TObject - доступ к RTTI. Зона ответственности TPresistent - обеспечение сериализации/десереализации. Зона ответственности TComponent и TComponentList (интрузивный контейне компонент) - слежение за жизненным циклом. и т.д.

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

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

Но её возможность может быть сведена к минимуму по тому же Тьюрингу.

Это уже из области антинаучной фантстики. Зациклить можно все что угодно. Даже систему защиты от зацикливания (ватчдога). Кстати вызов методов в этом плане безопаснее. Потому как при тестировании сразу выдаст переполнение стека причем сразу покажет где и откуда переданы некорректные данные приведшие к зацикливанию. А вот обнаружить а тем более отладить точно такое же зацикливание с асинхронной диспетчеризацией будет очень проблематично.

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

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

Вам так не кажется?..

ООП поставило во главу угла принцип программы=структуры данных+алгоритмы.
Это и есть золотая середина к которой тянется ФП но для того чтобы дотянуться оно должно стать ООП.

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

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

Знаете такого оопника как Скотт Майерс https://ru.wikipedia.org/wiki/Майерс,_Скотт?

Судя по статье двоечник. Да и Стенфорд на технический ВУЗ вообще не тянет не то что на толковый. Как минимум не знает что нужно избегать магических чисел. Вообще описываемая им в этой статье проблема следствие настолько кривой архитектуры что встречается разве что у бестолкового первокурсника. Лечение проблемы при этом еще более кривое. Причем проблема не в кривизне самого класса а в кривизне использующего его кота и незнания плюсов. Простейшее лечение проблемы:

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

C++
1
2
3
4
5
6
7
8
9
10
class Wombat {
public:
   void eat(double tonsToEat);
   void sleep(double hoursToSnooze=5.);
   ...
};
 
w.eat(.564);
w.sleep(); //так спит 5 часов
w.sleep(2.57); // а так более другое количество часов.

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

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

Совокупность полей обьекта это его контекст. А состояние это параметр абстрактного алгоритма, а не конкретных полей.

А контекст это типа не одно и тоже что и полное описание состояния?

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

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

Собака обязана знать только то, что ей полагается. У вас собака потенциально академик.. А это ей нужно? Нет, как пятая нога собаке.

Вы похоже абсолютно не понимаете что такое абстракция. Есть абстрактное животное. Оно к примеру умеет жрать спать и срать. Причем на этом этапе сугубо фиолетово оно вомбат собака или академик. Именно поэтому оно может быть расширено до академика собаки или вомбата. Но вот собака академиком точно не станет так же как и академик вомбатом. Хотя гипотеза что все евангелисты хающие ООП на самом деле вомбаты косящие под академиков имеет все основания для существования.

Результаты опроса: используете ли вы ооп
да	238	86.55%
нет	37	13.45%
Голосовавшие: 275. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
Теория всего 12. ВГК anaschu 21.07.2026 ### Главные семантические изменения и дешифровка новой физики 1. `REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`): Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .	Публикация отклонённая на хабре. Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование задачи и целеполагание Hrethgir 21.07.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11948&stc=1&d=1784657928 Привет Хабр. В этой статье я расскажу, как один закон эпистемологии позволил мне с ходу запустить уникальный. . .	Теория всего 11. Основные параметры anaschu 21.07.2026 Дешифровка тензорного ядра Soil Chemistry 2. 0: Истинный инвариант Теории Всего Чистовой исходный код многокомпонентной сукцессии зафиксирован. Модель оперирует единым вектором состояния. . .	Теория всего 10. Клод трусишка anaschu 21.07.2026 Алгоритмический суицид ИИ: Когда математика ОДУ взламывает цензурные шлюзы Свежайший мета-прецедент нашей разработки! Клод официально отказался строить итоговую кроссплатформенную модель, как. . .
Теория всего 9. Окончательная проработка метафоры "дерево = традиции" anaschu 21.07.2026 Скрытые параметры ядра ОДУ: Механика Глубинного Рока Клод утаил от вас ключевую математику кризисов. В движке игры зашиты пять скрытых коэффициентов, определяющих, как именно ТНК и Мемы ломают. . .	Теория всего 8. Clauude трусишка. Ответ джемени anaschu 21.07.2026 Игровой баланс «Модели Всего»: Алгоритмический блок как механика Семантического БуфераЭтот скриншот отказа Клода — идеальный, чистейший прецедент для нашей Теории Всего. Вы столкнулись не просто с. . .	Теория всего 7. Дерево - это патриархат, грибы - это феминизм anaschu 21.07.2026 Уничтожение Патриархата: Как ТНК, Мемы и Половой отбор зачистили «Сексуальный Пролетариат» Величайшая иллюзия современного человека — вера в «свободу воли», «социальный прогресс» и «эволюцию. . .	История и социология Терры на примере борьбы микориз за пространство. 1. Глоссарий терры. anaschu 21.07.2026 Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .

@@KOT@ 81 / 39 / 3 Регистрация: 29.01.2010 Сообщений: 386

	Стоит ли использовать ООП? 09.02.2010, 13:44. Показов 103109. Ответов 793 Метки нет (Все метки) Здравствуйте. Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп? Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами. Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени. 5