Используете ли Вы ООП по максимому или избегаете его ? - страница 11

[Denis Kirichenko]

comp:
Вы ведете речь о создании интерфейса. Но что мешает и без абстрактных классов это делать, создавая для виртуальных функций тело в виде одного return? Или это совсем не одно и то же.

Сам понял чего сказал? ;-)

[[Удален]]

Dennis Kirichenko:
Сам понял чего сказал? ;-)

Да.

[TheXpert]

comp:
Да.

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

[[Удален]]

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

Можно пример? Правда, не уловил разницу.

[TheXpert]

comp:
Можно пример? Правда, не уловил разницу.

Хз правильный ли синтакс, надеюсь будет понятно

class Virtual
{
   virtual void Do()
   {
      Print("Virtual::Do");
   }
};
class Abstract
{
   virtual void Do() = 0
   {
      Print("Abstract::Do");
   }
};
class VirtualImpl
   : public Virtual
{
};
class VirtualImpl2
   : public Virtual
{
   void Do()
   {
      Print("VirtualImpl2::Do");
   }
};
class AbstractImpl
   : public Abstract
{
};
class AbstractCorrectImpl
   : public Abstract
{
   void Do()
   {
      Print("AbstractCorrectImpl::Do");
   }
};

int OnInit()
{
   VirtualImpl o1; o1.Do();  // Virtual::Do
   VirtualImpl2 o2; o2.Do(); // VirtualImpl2::Do
   AbstractImpl o3; o3.Do(); // ошибка компиляции
   AbstractCorrectImpl o4; o4.Do(); // AbstractCorrectImpl::Do
   o4::Abstract.Do(); // Abstract::Do
   
   return(INIT_SUCCEEDED);
}

[[Удален]]

Комбинатор:

Хз правильный ли синтакс, надеюсь будет понятно

Спасибо за пример. Вся затея, как понимаю, чтобы была ошибка компиляции. Не понял только, в каких случаях это может быть полезно? Понимаю, что это как-то должно помочь не делать ошибки. Ну как с const, например. Но если с const все ясно почти сразу, стоит только начать писать. То с абстрактным такого понимания нет. Ведь если Virtual сделать return изначально, то можно будет создать объект такого типа. Но что хорошего, если теперь компилятор будет ругаться на такие объекты?

 

Программеры 100% не зря придумали интерфейсы. Но в чем явное удобство - не уловил.

[TheXpert]

comp:

Программеры 100% не зря придумали интерфейсы. Но в чем явное удобство - не уловил.

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

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

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

[Yuriy Asaulenko]

Комбинатор:

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

Я, видимо, что-то пропустил. В MQL есть (появились) интерфейсы? Дайте ссылку, плиз. Или расскажите подробней.

[[Удален]]

Комбинатор:

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

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

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

Попробую осознать. Пока не понял.

[sigma7i]

Yuriy Asaulenko:
Я, видимо, что-то пропустил. В MQL есть (появились) интерфейсы? Дайте ссылку, плиз. Или расскажите подробней.

В википедии хорошо описано, я процитирую никто не против :)

---

Можно заметить, что интерфейс, с формальной точки зрения, — это просто чистый абстрактный класс, то есть класс, в котором не определено ничего, кроме абстрактных методов. Если язык программирования поддерживает множественное наследование и абстрактные методы (как, например, C++), то необходимости во введении в синтаксис языка отдельного понятия «интерфейс» не возникает. Данные сущности описываются с помощью абстрактных классов и наследуются классами для реализации абстрактных методов.

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

---

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

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

Но когда приходит время поддержки, доработки, отладки, то все встает на свои места, ибо написание кода это 1/4 от всей разработки.