C#의 봉인 된 키워드를 읽었습니다. 내가 표준 라이브러리에서 물려받은 마지막 순간을 기억하지 못한다. C++에서는 typedef 타입을 사용하고 매개 변수를 사용하는 std 인터페이스를 상속 한 것을 기억합니다. 하지만 그건 1) 사소한 것 2) 인터페이스사소한 클래스를 상속하는 사례가 있습니까?
내 머리 꼭대기에서 상속받을 수있는 가상 함수가 없다는 것을 상속 한 클래스는 기억이 안납니다. 누구나 당신이 인터페이스가 아닌 사소한 클래스를 상속해야하는 상황을 말해 줄 수 있습니까?
가상 기능이없는 경우 클래스를 상속하지 않는 것이 좋은 규칙이라고 할 수도 있습니다. 이것은 좋은 경험일까요?
참고 : 저는 연산자 SomeClass를 사용합니다. & SomeClass() {return m_someClass; } 나는 다른 클래스로 내 개체를 전달해야 할 경우. 잘 작동한다.
실제로 C++에서 사용되는 모든 상속 관계 (예 : 구현, mixins, boost :: noncopyable 상속, 클래스를 상속 받아 클래스를 복사 불가능하게 만드는 것) : 연산자를 사용하면 일부 클래스에서 상속되고 일부 연산자가 클래스에 추가됩니다. 또한 C++ 유형으로 메타 프로그래밍을 수행 할 때 다른 유형을 상속하는 것은 유형을 구성하는 가장 간단한 방법 중 하나입니다.
가상 함수가없고 인터페이스의 "종류"로 사용되는 클래스에서 상속받은 또 다른 경우는 고정 다형성 (CRTP와 같은 Concrete 클래스 : BaseA와 같은 기술)입니다. 모든 것은 컴파일 타임에 해결되기 때문에 가상 함수가 필요하지 않습니다.
그러나 클래스를 다형 적으로 런타임으로 처리하려면 실제로 적어도 하나의 메소드를 가상으로 만들어야하며 이것이 소멸자가되어야합니다. 예외는 있지만 희귀합니다.
다형성 계층 구조를 가지고 있더라도 구체적인 클래스에서 파생되는 경우가 있습니다. 한 가지 예가 TextEdit에서 파생 된 SingleLineEdit입니다. 그러나 이것은 약간 위험합니다. 부모 클래스의 캡슐화가 끊어지기 때문입니다 (예 : 메소드가 구현 세부 사항을 기대할 수 있고 하위 클래스에서이를 존중하고 보존해야합니다. 구현 세부 사항이 될 수 있으므로 까다로울 수 있음). 다음 버전에서 예고없이 변경)
나는 객체 지향 프로그래밍의 핵심 개념이 다형성이라고 주장 할 것이다. 특정 클래스에서 상속하면 다형성을 활용할 수 없으며 상속의 요지는 무엇입니까? 따라서 오버라이드 할 메소드가 없으면 서브 클래스를 작성하지 마십시오. 코드의 복잡성 만 증가시킬 수 있습니다. 동일한 기능을 원하는 경우 기존 클래스를 직접 포장하십시오.
OOD의 핵심 개념은 데이터와 기능이 함께 수집되어 모델링 대상을 나타내는 개체를 형성한다는 것입니다. 다형성은 그 개념을 확장 한 것입니다. –
OOP의 핵심 개념은 누구도 그것이 무엇인지 동의 할 수 없다는 것입니다. 다형성은 그 개념을 확장 한 것으로, "데이터와 기능을 함께 수집하여 객체를 형성하지 않고"다형성을 가질 수 있다고 가정합니다. –
그럼에도 불구하고 상속의 주된 목적은 실제 객체를 나타내는 것이 아니라 다형성을 촉진하는 것입니다. 실제 객체를 모델링하기 위해 OOP를 사용하는 것이 어떻게 작동하지 않는지 Liskov Substitution Principle을 살펴보십시오. – Smashery