아니요, 저는 많은 가상 기능 을 정의하고 필요에 따라 상속인에게 과부하를 걸고 싶었습니다.
그것은 완전한 혼돈과 통제력 부족입니다. 인터페이스는 "필요한" 것이 아니라 구현 해야 하는 추상 메서드를 정의합니다. 이렇게 하면 개체에서 이러한 메서드가 구현됩니다. 그리고 귀하의 접근 방식을 사용하면 어딘가에 메소드를 오버로드하는 것을 잊은 경우 프로그램이 아무 일도 일어나지 않은 것처럼 컴파일되고 원하는 메소드 대신 더미만 호출됩니다. 평범해서...
Alexey Navoykov : 그것은 완전한 혼돈과 통제력 부족입니다. 인터페이스는 "필요한" 것이 아니라 구현 해야 하는 추상 메서드를 정의합니다. 이렇게 하면 개체에서 이러한 메서드가 구현됩니다. 그리고 귀하의 접근 방식을 사용하면 어딘가에 메소드를 오버로드하는 것을 잊은 경우 프로그램이 아무 일도 일어나지 않은 것처럼 컴파일되고 원하는 메소드 대신 더미만 호출됩니다. 평범해서...
제 생각에는 모든 것이 그렇게 나쁜 것은 아닙니다. 내 생각에는 동일한 C#에 기본 기본 인터페이스가 많지 않으므로(저는 C# 전문가가 아닙니다) 해당 메서드를 하나의 기본 슈퍼클래스로 축소한 다음 필요한 사람이 상속할 수 없습니다.
"누구에게 필요한 것을 상속받는다"는 것은 무엇을 이해합니까? 전체 클래스가 아니라 일부를 상속하시겠습니까? ) 그런 기능을 모르는 것
아니요, 저는 많은 가상 기능 을 정의하고 필요에 따라 상속인에게 과부하를 걸고 싶었습니다.
아니요, 저는 많은 가상 기능 을 정의하고 필요에 따라 상속인에게 과부하를 걸고 싶었습니다.
그것은 완전한 혼돈과 통제력 부족입니다. 인터페이스는 "필요한" 것이 아니라 구현 해야 하는 추상 메서드를 정의합니다. 이렇게 하면 개체에서 이러한 메서드가 구현됩니다. 그리고 귀하의 접근 방식을 사용하면 어딘가에 메소드를 오버로드하는 것을 잊은 경우 프로그램이 아무 일도 일어나지 않은 것처럼 컴파일되고 원하는 메소드 대신 더미만 호출됩니다. 평범해서...
더미가 아니라 "구현되지 않은" 예외입니다. C#에서는 항상 그런 것 같습니다.
... 어딘가에 메소드를 오버로드하는 것을 잊었다면 아무 일도 없었던 것처럼 프로그램이 컴파일되고 원하는 메소드 대신 더미만 호출됩니다. 평범해서...
그건 그렇고, MQL에서 이것이 정확히 모든 것이 작동하는 방식입니다.
더미가 아니라 "구현되지 않은" 예외입니다. C#에서도 아주 자주 그런 것 같습니다.
그건 그렇고, MQL에서 이것이 정확히 모든 것이 작동하는 방식입니다.
요점이 아닙니다. 런타임에 버그를 잡을 것을 제안하지만 이러한 버그는 컴파일 단계에서 잡을 수 있고 잡아야 합니다.
클래스에 대해 템플릿 <,,,,,,,,>과 같은 구성을 쌓는 것보다 이것이 어떤 면에서 더 낫다고 생각합니다. 그런 "계급 시스템" 구축을 마치기도 전에 두뇌가 부서질 것입니다.
클래스에 대해 템플릿 <,,,,,,,,>과 같은 구성을 쌓는 것보다 이것이 어떤 면에서 더 낫다고 생각합니다. 그런 "계급 시스템" 구축을 마치기도 전에 두뇌가 부서질 것입니다.
난 동의하지 않는다. 컴파일러를 엉망으로 만들고 싶지만 내 프로그램이 올바르게 작동하고 작업자 메서드가 호출되고 지옥이 아닌 것이 보장됩니다.
이 모든 것이 기본적으로 모든 곳에 나타나는 단순한 기본 클래스와 캐스트 역학이 있는 경우 작동할 수 있습니다)