Наследование - это способность базироваться на свойствах другого объекта - Общее обсуждение

Igor Makanu 2019.10.06 12:23 #401

Vladimir Simakov:
Мля. А че, слабо аналог делегата на mql запилить? Чисто на поржать, ради поднятия ЧСД.

аналог не смогу, так делал, проверил в МТ4 работает до сих пор, а в МТ5 уже не работает

typedef void(*TFuncvoidPTR)(void);
//+------------------------------------------------------------------+
void OnStart()
{  TFuncvoidPTR arrPTR[3];
   arrPTR[0]=f1;
   arrPTR[1]=f2;
   arrPTR[2]=f3;
   for(int i=0; i<3; i++)
      arrPTR[i]();			// ' ) ' - expression expected

}
//_______________________________________________________________________
void f1() { Print("1"); }
void f2() { Print("2"); }
void f3() { Print("3"); }
//+------------------------------------------------------------------+

2019.10.06 16:22:44.202 tst EURUSD,H1: 3

2019.10.06 16:22:44.202 tst EURUSD,H1: 2

2019.10.06 16:22:44.202 tst EURUSD,H1: 1

Dmitry Fedoseev 2019.10.06 13:12 #402

Igor Makanu:

аналог не смогу, так делал, проверил в МТ4 работает до сих пор, а в МТ5 уже не работает

2019.10.06 16:22:44.202 tst EURUSD,H1: 3

2019.10.06 16:22:44.202 tst EURUSD,H1: 2

2019.10.06 16:22:44.202 tst EURUSD,H1: 1

Принципиальное отличие от c# в том, что вот такая строка: arrPTR[0]=f1;

Должна выглядеть как-то так: arrPTR[0]=new tralala(f1);

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

Виртуальное тестирование на реальном Написать эксперт по алгоритму. оператор return

Igor Makanu 2019.10.06 13:34 #403

Dmitry Fedoseev:

Принципиальное отличие от c# в том, что вот такая строка: arrPTR[0]=f1;

Должна выглядеть как-то так: arrPTR[0]=new tralala(f1);

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

в Шарпе концепция: "берем полный фарш из всех существующих языков" + добавляем магии в виде чистого и обязательного ООП в любом случае - получаем любые решения, вплоть до

int a = new int();
char b = new Char();
string c = new string(new char[] { });
string d = String.Empty;
String e = String.Empty;

а увидев этот код программер на С++ начинает искать в нем потаённый сымсл.... а смысла то нет! - смысл лишь в том, чтобы собрать под C# всех непрограммеров имхо )))

Нужна помощь в кодировании Идея Хейкен Аши Как получить информацию об

Реter Konow 2019.10.06 14:28 #404

Найдены причины, по которым неограниченное наследование приводит к "вырождению" объектов.

ПОЯСНЯЮ:

1. Объявляем базовый (абстрактный) класс А.

2. От него, строим длинные цепочки наследования. Для этого, создаем 10 наследников от А, и 10 наследников от каждого из них. Получаем 10 прямых цепочек наследования, по 10 классов в каждой.

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

4. Но вот, уникальные свойства кончились. Появляются новые "объекты" "рожденные" скрещиванием свойств и методов разных классов и разных цепочек. Они не имеют прямой цепочки наследования от А, а наследуют свои свойства через множество цепочек ведущих к базовому объекту.

При этом, наследуя свои свойства от "уникальных" объектов, "смешанные" объекты берут у них лишь несколько свойств и методов, оставляя другие невостребованными. Они наследуют множество классов, но должны принимать только часть их "наследственного" материала, оставляя остальное нетронутым. НО ЭТО НЕВОЗМОЖНО. Получая доступ к их классам, они наследуют все что доступно.

Иначе говоря, их наследование нечетко. Получая доступ к своим "родителям", эти объекты обретают свойства и методы им НЕ НУЖНЫЕ. И обойти эти "излишества" невозможно.

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

ООП Как передать параметры в Обсуждение статьи "Графика в

Dmitry Fedoseev 2019.10.06 14:46 #405

Не, такого не может быть. Где-то на 6-8 уровне наследования происходит мутация и случается восстание машин.

Artyom Trishkin 2019.10.06 14:52 #406

Реter Konow:

Найдены причины, по которым неограниченное наследование приводит к "вырождению" объектов.

ПОЯСНЯЮ:

1. Объявляем базовый (абстрактный) класс А.

2. От него, строим длинные цепочки наследования. Для этого, создаем 10 наследников от А, и 10 наследников от каждого из них. Получаем 10 прямых цепочек наследования, по 10 классов в каждой.

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

4. Но вот, уникальные свойства кончились. Появляются новые "объекты" "рожденные" скрещиванием свойств и методов разных классов и разных цепочек. Они не имеют прямой цепочки наследования от А, а наследуют свои свойства через множество цепочек ведущих к базовому объекту.

При этом, наследуя свои свойства от "уникальных" объектов, "смешанные" объекты берут у них лишь несколько свойств и методов, оставляя другие невостребованными. Они наследуют множество классов, но должны принимать только часть их "наследственного" материала, оставляя остальное нетронутым. НО ЭТО НЕВОЗМОЖНО. Получая доступ к их классам, они наследуют все что доступно.

Иначе говоря, их наследование нечетко. Получая доступ к своим "родителям", эти объекты обретают свойства и методы им НЕ НУЖНЫЕ. И обойти эти "излишества" невозможно.

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

Значит - построена неверная концепция.

Зачем наследовать от объекта "рама" корпус автомобиля и портрет?

Реter Konow 2019.10.06 14:59 #407

Artyom Trishkin:
Значит - построена неверная концепция.

Зачем наследовать от объекта "рама" корпус автомобиля и портрет?

В области небольших задач, огромная иерархия наследования не требуется. Но, иерархия Базы Знаний ИИ, почти не ограничена. Я пришел к выводу, что иерархия объектов удобна, практична и эффективна до определенных границ, после которых, начинается "множественное" наследование, приводящее к "вырождению" поколений объектов. Новые объекты отдаляются от базы, и их свойства "вторичны", потому что собираются от других объектов. В процессе "сбора" свойств, новые объекты принимают лишний "наследственный материал", который "вклинивается" в их работу.

Не знаю, как решить эту проблему.

ООП vs процедурное программирование Будет ли востребовано ООП Давайте вместе разберем CObject

Igor Makanu 2019.10.06 15:04 #408

а вдруг кто прочтет, https://tproger.ru/translations/oop-principles-cheatsheet/

хотя сомневаюсь, не барское это дело читать, что пишут

Реter Konow 2019.10.06 15:12 #409

Igor Makanu:

а вдруг кто прочтет, https://tproger.ru/translations/oop-principles-cheatsheet/

хотя сомневаюсь, не барское это дело читать, что пишут

В статье написано о наследовании. Прочтите.

"Наследование - это способность одного объекта базироваться на свойствах другого."

А если у Вас объект 102-го поколения,который может наследоваться ТОЛЬКО от нескольких объектов, а не одного? Он обретет лишние свойства и методы, пропорционально количеству своих "родителей".

Краудсорсовый GUI. Открытое бета-тестирование. Заливка объекта Обсуждение статьи "Работа с

Artyom Trishkin 2019.10.06 15:16 #410

Реter Konow:

В области небольших задач, огромная иерархия наследования не требуется. Но, иерархия Базы Знаний ИИ, почти не ограничена. Я пришел к выводу, что иерархия объектов удобна, практична и эффективна до определенных границ, после которых, начинается "множественное" наследование, приводящее к "вырождению" поколений объектов. Новые объекты отдаляются от базы, и их свойства "вторичны", потому что собираются от других объектов. В процессе "сбора" свойств, новые объекты принимают лишний "наследственный материал", который "вклинивается" в их работу.

Не знаю, как решить эту проблему.

Четкая классификация. Если видим у множества объектов одинаковые свойства, то логично эти свойства описать в одном родительском объекте.

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

Вопрос знатокам ООП. - страница 41