Artyom Trishkin : 명확한 분류. 많은 객체가 동일한 속성을 가지고 있다는 것을 알면 이러한 속성을 하나의 상위 객체로 설명하는 것이 논리적입니다.
자식 개체가 같은 이름의 부모 속성을 재정의하는 경우 해당 속성은 가상이어야 합니다.
객체가 다른 클래스의 속성과 메서드를 상속하면 어떻게 될까요?
증가하고 동적으로 재구축 되는 데이터 구조 (지식 기반)를 다루는 경우 기성품의 "유전 자료"를 사용하여 새 것을 생성해야 합니다. 이 경우 개체는 다중 상속으로 합성되어 추가 유전 물질을 가져옵니다. 따라서 정상적으로 작동하지 않습니다. 즉, 다중 상속이 시작되자마자 객체의 퇴화에 이르게 된다. 이것은 문제예요...
증가하고 동적으로 재구축 되는 데이터 구조 (지식 기반)를 다루는 경우 기성품의 "유전 자료"를 사용하여 새 것을 생성해야 합니다. 이 경우 개체는 다중 상속으로 합성되어 추가 유전 물질을 가져옵니다. 따라서 정상적으로 작동하지 않습니다. 즉, 다중 상속이 시작되자마자 객체의 퇴화에 이르게 된다. 이것은 문제예요...
새 개체에서 "왼쪽" 부모의 속성을 사용하지 마십시오. 비록 나는 당신에게서 약간의 오해를 봅니다. 속성이 필요하지 않은 개체에서 개체를 "스폰"하는 이유는 무엇입니까?
개발자들은 사용자 정의 기호, 서비스, 눈금, 캐시, 핍 등을 도입했습니다. 필요한 경우 단위.
테스터의 새로운 pip 모드를 살펴보겠습니다. 누가 필요합니까? - 사실 아무도! 이 모드는 개발자에 의한 테스터의 중요한 알고리즘 최적화의 비전으로 탄생했습니다. 누가 그 유용성을 이해했습니까? -없음! 모든 면에서 그렇습니다.
이제 테스터가 크게 수정되었습니다. 따라서 이러한 수정 nafig는 누구에게도 포기하지 않았습니다. 글쎄, 그것을 높이 평가할 괴짜가 있습니다. 현재 형태에서 MT5-Tester는 모든 경쟁자보다 우수합니다. 그러나 어떤 이유로 그들은 더 시원하게 만들고 싶어합니다. 동시에 미래의 기능은 고사하고 현재 기능을 평가할 수 있는 사람은 아무도 없습니다. 개발자는 사용자보다 몇 배나 더 키가 큽니다. 그리고 분명히 테스터의 변화에 대한 동기는 수익 창출(아무도 이해하지 못한다면 불가능함)이 아니라 전례 없는 일을 하려는 내부 욕구입니다.
명확한 분류. 많은 객체가 동일한 속성을 가지고 있다는 것을 알면 이러한 속성을 하나의 상위 객체로 설명하는 것이 논리적입니다.
객체가 다른 클래스의 속성과 메서드를 상속하면 어떻게 될까요?
증가하고 동적으로 재구축 되는 데이터 구조 (지식 기반)를 다루는 경우 기성품의 "유전 자료"를 사용하여 새 것을 생성해야 합니다. 이 경우 개체는 다중 상속으로 합성되어 추가 유전 물질을 가져옵니다. 따라서 정상적으로 작동하지 않습니다. 즉, 다중 상속이 시작되자마자 객체의 퇴화에 이르게 된다. 이것은 문제예요...
객체가 다른 클래스의 속성과 메서드를 상속하면 어떻게 될까요?
증가하고 동적으로 재구축 되는 데이터 구조 (지식 기반)를 다루는 경우 기성품의 "유전 자료"를 사용하여 새 것을 생성해야 합니다. 이 경우 개체는 다중 상속으로 합성되어 추가 유전 물질을 가져옵니다. 따라서 정상적으로 작동하지 않습니다. 즉, 다중 상속이 시작되자마자 객체의 퇴화에 이르게 된다. 이것은 문제예요...
해당 툴킷이 게시됩니다. 작성자 외에는 필요하지 않습니다.
그리고 이것 은 여전히 필요 합니다 . 그러나 그에게도 아무도 필요하지 않을 것입니다.
KB, 기사 등도 같은 상황입니다.
개발자들은 사용자 정의 기호, 서비스, 눈금, 캐시, 핍 등을 도입했습니다. 필요한 경우 단위.
테스터의 새로운 pip 모드를 살펴보겠습니다. 누가 필요합니까? - 사실 아무도! 이 모드는 개발자에 의한 테스터의 중요한 알고리즘 최적화의 비전으로 탄생했습니다. 누가 그 유용성을 이해했습니까? -없음! 모든 면에서 그렇습니다.
이제 테스터가 크게 수정되었습니다. 따라서 이러한 수정 nafig는 누구에게도 포기하지 않았습니다. 글쎄, 그것을 높이 평가할 괴짜가 있습니다. 현재 형태에서 MT5-Tester는 모든 경쟁자보다 우수합니다. 그러나 어떤 이유로 그들은 더 시원하게 만들고 싶어합니다. 동시에 미래의 기능은 고사하고 현재 기능을 평가할 수 있는 사람은 아무도 없습니다. 개발자는 사용자보다 몇 배나 더 키가 큽니다. 그리고 분명히 테스터의 변화에 대한 동기는 수익 창출(아무도 이해하지 못한다면 불가능함)이 아니라 전례 없는 일을 하려는 내부 욕구입니다.
새 개체에서 "왼쪽" 부모의 속성을 사용하지 마십시오. 비록 나는 당신에게서 약간의 오해를 봅니다. 속성이 필요하지 않은 개체에서 개체를 "스폰"하는 이유는 무엇입니까?
필요하지만 완전히는 아닙니다. 새 개체는 3개의 클래스 A 속성, 5개의 클래스 B 속성 및 3개의 추가 클래스에서 3개의 메서드를 사용합니다.
그는 이 클래스의 나머지 속성을 어떻게 처리해야 합니까? 그들로부터 그것을 제한하는 방법?
필요하지만 완전히는 아닙니다. 새 개체는 3개의 클래스 A 속성, 5개의 클래스 B 속성 및 3개의 추가 클래스에서 3개의 메서드를 사용합니다.
그는 이 클래스의 나머지 속성을 어떻게 처리해야 합니까? 그들로부터 그것을 제한하는 방법?
새로운 대상에 하트가 필요한 경우 하트에서 상속할 필요가 없습니다. 하트는 회원처럼 새 대상의 일부가 되어야 합니다.
새 개체가 개체의 조상인 경우 상속되어야 합니다. 새 객체에 다른 객체가 포함되어 있으면 포함을 사용하십시오.
A 클래스의 3가지 속성을 객체로 묶습니다. 그에게서 상속하십시오. 또는 상속할 수 없지만 세 가지 속성을 가진 개체를 필수 개체의 속성으로 만듭니다.
세 가지 속성을 하나의 개체로 결합하여 새 개체의 속성으로 만드시겠습니까? 생각해야지...
그러나 많은 긴 사슬을 통한 상속은 모든 단계에서 유사한 문제를 만듭니다. 상속 체인이 더 길고 다양할수록 마지막 세대의 개체가 속성과 메서드를 더 "혼합"하게 되고 개별 체인을 기본 개체로 분리하는 것이 더 어려워집니다.
상속하지 않으면 기본 개체에 액세스할 수 없습니다. 상속하는 경우 - 개체의 다중 "상위"는 기본 개체에 대한 직접 체인을 추적하는 것을 방지합니다.
자신의 속성과 메서드를 다른 클래스에서 분리하는 것이 점점 더 어려워지고 있습니다.
세 가지 속성을 하나의 개체로 결합하여 새 개체의 속성으로 만드시겠습니까? 생각해야지...
그러나 많은 긴 사슬을 통한 상속은 모든 단계에서 유사한 문제를 만듭니다. 상속 체인이 더 길고 다양할수록 마지막 세대의 개체가 속성과 메서드를 더 "혼합"하게 되고 개별 체인을 기본 개체로 분리하는 것이 더 어려워집니다.
상속하지 않으면 기본 개체에 액세스할 수 없습니다. 상속하는 경우 - 개체의 다중 "상위"는 기본 개체에 대한 직접 체인을 추적하는 것을 방지합니다.
자신의 속성과 메서드를 다른 클래스에서 분리하는 것이 점점 더 어려워지고 있습니다.
피터, 추천합니다
https://en.wikipedia.org/wiki/Code_Complete
새로운 대상에 하트가 필요한 경우 하트에서 상속할 필요가 없습니다. 하트는 회원처럼 새 대상의 일부가 되어야 합니다.
새 개체가 개체의 조상인 경우 상속되어야 합니다. 새 객체에 다른 객체가 포함되어 있으면 포함을 사용하십시오.
세 가지 속성을 하나의 개체로 결합하여 새 개체의 속성으로 만드시겠습니까? 생각해야지...
그러나 많은 긴 사슬을 통한 상속은 모든 단계에서 유사한 문제를 만듭니다. 상속 체인이 더 길고 다양할수록 마지막 세대의 개체가 속성과 메서드를 더 "혼합"하게 되고 개별 체인을 기본 개체로 분리하는 것이 더 어려워집니다.
상속하지 않으면 기본 개체에 액세스할 수 없습니다. 상속하는 경우 - 개체의 다중 "상위"는 기본 개체에 대한 직접 체인을 추적하는 것을 방지합니다.
자신의 속성과 메서드를 다른 클래스에서 분리하는 것이 점점 더 어려워지고 있습니다.