Perguntas OOP (Object Oriented Programming) - página 7

Novo comentário
 
Zhunko:

Vasily, um exemplo, por favor!

Só conheço um caso em que você precisa alocar memória e precisa de um ponteiro para isso.

Tenho certeza de que quase sempre se pode passar sem ele. É desejável não utilizar o gerenciamento manual de memória. Há sempre uma biblioteca padrão que já resolveu estes problemas.


enum ENUM_CLASS_TYPE
{
   CLASS_PARENT,
   CLASS_CHILD_1,
   CLASS_CHILD_2
};

class Parent
{
   public:
      ENUM_CLASS_TYPE(void){return classType;}
      virtual string GetName(){return "Base";}
   protected:
      Parent(ENUM_CLASS_TYPE type){classType = type;}
   private:
      ENUM_CLASS_TYPE classType;
};

class Child1 : public Parent
{
   public:
      Child1() : Parent(CLASS_CHILD_1){;}
      void MethodChild1(){;}
};

class Child2 : public Parent
{
   public:
      Child2() : Parent(CLASS_CHILD_2){;}
      void MethodChild2(){;}
};

int Start()
{
   Parent* parent = new Child1();
   switch(parent.GetType())
   {
      case CLASS_CHILD_1:
      {
          Child1* ch = parent;
          ch.MethodChild2();
          break;
      }
      case CLASS_CHILD_2:
      {
          Child1* ch = parent;
          ch.MethodChild2();
          break;
      }
   }
}
 
TheXpert:
A presença de identificação de tipo dinâmico geralmente indica a arquitetura de muleta do projeto.


A presença do tipo de identificação dinâmica indica um alto grau de polimorfismo e um maior nível de abstração. Aumenta a capacidade de gerenciamento e a escalabilidade do projeto. Permite trabalhar com código no nível da interface e incentiva o programador a não entrar em detalhes de implementação.
 
Vasily, eu acho que seu exemplo está fora de alcance. Existem modelos (macros em µl), eles podem resolver muitos problemas em tempo de compilação. E se você tiver que fazer a conversão para baixo, você não projetou bem o programa (até mesmo Straustrup disse isso).
 
Pavlick:
Vasily, eu acho que seu exemplo está fora de alcance. Existem modelos (macros em µl), eles podem resolver muitos problemas na fase de compilação. E se você tiver que fazer a conversão para baixo, o programa foi mal concebido (até mesmo Straustrup disse isso).

O que há de errado com a engrenagem para baixo com controle rígido do tipo? Straustrup disse isto quando não havia nenhum tipo de controle. Agora, se você conhece o tipo derivado, você pode garantir a conversão antes que ela comece e assim evitar erros de tempo de execução.

Mas as vantagens da baixa conversão são óbvias. A principal delas é que funciona no nível da interface. Se o construtor de uma classe base é fechado no escopo protegido, é uma classe de interface e abstrata e podemos trabalhar com ela em seu nível sem ter que conhecer a refinada implementação de seus descendentes. Mas se implementarmos um comportamento polimórfico dependendo do tipo de instância, podemos certamente especificar a implementação da instância correspondente e, por exemplo, chamar seu método único. Com funções virtuais, não precisaremos nem mesmo de conversão de tipo. Afinal, as funções virtuais chamarão a implementação específica de "bastidores".

 
C-4:

... Com funções virtuais, mesmo uma conversão de tipo não será necessária. Afinal, as funções virtuais chamarão uma implementação particular de "bastidores".


Eu não tenho nada contra o destacado. No exemplo, o senhor adotou uma abordagem diferente.
C-4:

O que há de errado com a queda do elenco quando os tipos são estritamente controlados?

Se você o escreve corretamente, simplesmente não precisa dele.

P.S: Não estou colocando a identificação do tipo samapal e o mecanismo de função virtual na mesma garrafa.

 

Um exemplo de uma aplicação MQL real:

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

Eu gostaria de ouvir opiniões de especialistas sobre como eles resolveriam tal problema. Eu pessoalmente a resolvi usando identificação dinâmica de tipo, padrão "método padrão" e conversões de degrau para baixo. Foi resolvido tão bem que finalmente me permitiu criar tabelas interativas complexas com elementos irregulares e totalmente personalizáveis. Os resultados são tão tangíveis que acho ingênuo afirmar que a "identificação dinâmica é uma muleta" e a "baixa conversão é o mal".

p.s. Pavlick, a propósito, você ainda não respondeu o que exatamente está errado com a conversão para baixo.

 

Não, eu estou longe de ser um especialista. O que eu disse sobre a engrenagem de redução é minha experiência, eu me esforço para escrevê-la dessa forma + é confirmada por pessoas que eu respeito. Escrever um programa para provar algo é uma perda do meu tempo.

Pavlick, a propósito, você ainda não respondeu o que exatamente torna ruim o downsizing.

É difícil de explicar. Eu entendo, mas não posso dizer). Os livros provavelmente o explicarão melhor.

 
C-4:
enum ENUM_CLASS_TYPE
{
   CLASS_PARENT,
   CLASS_CHILD_1,
   CLASS_CHILD_2
};

class Parent
{
   public:
      ENUM_CLASS_TYPE(void){return classType;}
      virtual string GetName(){return "Base";}
   protected:
      Parent(ENUM_CLASS_TYPE type){classType = type;}
   private:
      ENUM_CLASS_TYPE classType;
};

class Child1 : public Parent
{
   public:
      Child1() : Parent(CLASS_CHILD_1){;}
      void MethodChild1(){;}
};

class Child2 : public Parent
{
   public:
      Child2() : Parent(CLASS_CHILD_2){;}
      void MethodChild2(){;}
};

int Start()
{
   Parent* parent = new Child1();
   switch(parent.GetType())
   {
      case CLASS_CHILD_1:
      {
          Child1* ch = parent;
          ch.MethodChild2(); // Это не ошибка?
          break;
      }
      case CLASS_CHILD_2:
      {
          Child1* ch = parent;// Это не ошибка?

          ch.MethodChild2();
          break;
      }
   }
}

Mesmo que não seja um erro, existem modelos e datilografias().
 
Pavlick:

Não, eu estou longe de ser um especialista.

Mas a Stroustrup é. E muitos outros também. Você está dizendo todas as coisas certas.
 
Typeid() infelizmente não existe, e a força dos gabaritos é a identificação estática. Problemas diferentes são resolvidos por métodos diferentes e dizer que um método é ruim e o outro é bom é uma suposição ahuld.
1234567891011
Novo comentário