OOP(객체 지향 프로그래밍)에 대한 질문 - 페이지 7

새 코멘트
 
Zhunko :

바실리, 예를 들어주세요!

메모리를 할당하고 포인터가 필요한 경우를 한 번만 알고 있습니다.

나는 당신이 거의 항상 그것 없이 할 수 있다고 확신합니다. 수동 메모리 관리를 사용하지 않는 것이 좋습니다. 이러한 문제가 이미 해결된 표준 라이브러리는 항상 있습니다.


 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 :
동적 유형 식별의 존재는 일반적으로 프로젝트의 목발 아키텍처를 나타냅니다.


동적 유형 식별의 존재는 높은 수준의 다형성 과 높은 수준의 추상화를 나타냅니다. 프로젝트 관리 용이성과 확장성을 높입니다. 인터페이스 수준에서 코드로 작업할 수 있게 하고 프로그래머가 구현 세부 사항에 들어가지 않도록 권장합니다.
 
Vasily, 내 생각에 당신의 모범은 삶과 관련이 없습니다. 템플릿(μl 단위의 매크로)이 있으며 컴파일 단계에서 많은 문제를 해결할 수 있습니다. 그리고 다운캐스트해야 한다면 프로그램을 잘못 설계한 것입니다(Strousstrup도 이에 대해 이야기했습니다).
 
Pavlick :
Vasily, 내 생각에 당신의 모범은 삶과 관련이 없습니다. 템플릿(μl 단위의 매크로)이 있으며 컴파일 단계에서 많은 문제를 해결할 수 있습니다. 그리고 다운캐스트해야 한다면 프로그램을 잘못 설계한 것입니다(Strousstrup도 이에 대해 이야기했습니다).

강력한 유형 검사를 사용한 다운캐스팅이 나쁜 이유는 무엇입니까? Stroustrup은 아직 유형 검사가 없을 때 이렇게 말했습니다. 이제 파생된 형식을 알면 시작하기 전에도 변환을 보장할 수 있으므로 런타임 오류를 피할 수 있습니다.

그러나 다운캐스팅의 장점은 분명합니다. 주요 작업은 인터페이스 수준에서 수행하는 작업입니다. 기본 클래스 생성자가 보호된 범위에서 닫히면 인터페이스 및 추상 클래스이며 자손의 지정 구현을 알 필요 없이 해당 수준에서 작업할 수 있습니다. 그러나 인스턴스 유형에 따라 다형성 동작을 구현하면 해당 인스턴스의 구현을 구체화할 수 있고 예를 들어 고유한 메서드만 호출할 수 있습니다. 가상 함수를 사용하면 짝수 유형 캐스팅이 필요하지 않습니다. 결국 가상 기능 은 "뒤에서" 구체적인 구현을 호출합니다.

 
C-4 :

... 가상 함수를 사용하면 짝수 유형 캐스팅이 필요하지 않습니다. 결국 가상 기능은 "뒤에서" 구체적인 구현을 호출합니다.


나는 선택에 반대할 것이 없다. 이 예에서는 다른 접근 방식을 선택했습니다.
C-4 :

강력한 유형 검사를 사용한 다운캐스팅이 나쁜 이유는 무엇입니까? ...

올바르게 작성하면 이것은 단순히 필요하지 않습니다.

추신: 나는 유형의 자기 식별과 가상 기능 의 메커니즘을 하나의 병에 결합하지 않습니다.

 

실제 MQL 애플리케이션의 예:

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

전문가들의 의견, 어떻게 비슷한 문제를 해결하기 시작할 것인지 듣고 싶습니다. 개인적으로 동적 유형 식별, "템플릿 방법" 패턴 및 다운캐스트의 도움으로 해결했습니다. 매우 잘 해결되어 결국에는 불규칙하고 완전히 사용자 정의 가능한 요소가 포함된 복잡한 대화형 테이블을 만들 수 있었습니다. 결과가 너무 가시적이어서 "동적 식별은 목발"이고 "다운그레이드는 악"이라고 말하는 것이 순진해 보입니다.

ps Pavlick, 그건 그렇고, 당신은 정확히 무엇이 나쁜 다운 캐스트인지 대답하지 않았습니다.

 

당신은 무엇입니까, 나는 전문가와 거리가 멀습니다. 제가 다운캐스팅에 대해 말한 것은 제 경험입니다. 저는 이렇게 쓰려고 노력합니다. + 제가 존경하는 사람들이 이것을 확인합니다. 무언가를 증명하기 위한 프로그램을 작성하기 위해, 나는 내 시간을 미안하게 생각합니다.

Pavlick, 그건 그렇고, 당신은 여전히 다운 캐스팅이 나쁜 이유에 대해 대답하지 않았습니다.

설명하기 어려운. 이해하지만 말할 수 없습니다)). 아마도 책이 더 잘 설명할 것입니다.

 
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.MethodChild 2 (); // Это не ошибка?
          break ;
      }
       case CLASS_CHILD_2:
      {
          Child 1 * ch = parent;// Это не ошибка?

          ch.MethodChild2();
           break ;
      }
   }
}

버그가 아니더라도 템플릿과 typeid()가 있습니다.
 
Pavlick :

당신은 무엇입니까, 나는 전문가와 거리가 멀습니다.

그러나 Stroustrup은 전문가입니다. 그리고 다른 많은 사람들도. 당신은 모두 맞습니다.
 
Typeid()는 불행히도 그렇지 않으며 템플릿의 힘은 정적 식별에 있습니다. 다른 작업은 다른 방법으로 해결되며 한 방법은 나쁘고 다른 방법은 좋다고 말하는 것은 민첩한 가정입니다.
1234567891011
새 코멘트