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
새 코멘트