물론 리소스와 많은 디버깅 시간으로 OOP의 아름다움에 대한 비용을 지불해야 합니다. OOP는 편리한 텍스트 래퍼로 또는 런타임 환경을 초기화할 때 최소한의 사용으로만 의미가 있습니다. 본질적으로 OOP 는 순전히 Microsoft에서 프로그래머의 작업 시간 비용을 늘리고 고급 장비의 구매를 촉진하기 위한 마케팅이었습니다. 게다가 그들 자신은 바보가 아니며 모든 소프트웨어를 C와 어셈블러로 작성합니다.
글쎄, 나는 이미 방법을 썼습니다 - 왜 작동하지 않습니까? 헤더 파일에 기술된 추상 클래스(인터페이스)를 반환 하는 팩토리 메서드 또는 함수를 만듭니다. 모든 구현이 숨겨져 있습니다. 예를 들어 내 블로그 에서 즉석에서 전문가 최적화 라이브러리 (영문)에 대한 실제 예를 찾을 수 있습니다.
Шаблон проектирования Тип: Назначение: Структура: Плюсы: Минусы: Описан в Design Patterns Фабричный метод (англ. также известен как Виртуальный конструктор (англ. )) — порождающий шаблон проектирования, предоставляющий подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой...
글쎄, 나는 이미 방법을 썼습니다 - 왜 작동하지 않습니까? 헤더 파일에 기술된 추상 클래스(인터페이스)를 반환 하는 팩토리 메서드 또는 함수를 만듭니다. 모든 구현이 숨겨져 있습니다. 예를 들어 내 블로그 에서 즉석에서 전문가 최적화 라이브러리 (영문)에 대한 실제 예를 찾을 수 있습니다.
소스를 배포하려고 합니다. 그리고 여기 위키에 대한 링크가 있으므로 모두가 알고 있습니다.
나는 당신에게 말하고 있습니다 - 그것을 시도하십시오. 그것은 엄청난 양의 코드입니다. 인스턴스화된 클래스 "СFoo: public InterfaceCFoo"는 InterfaceCFoo *privateContext 필드(1:1 연결 만들기)를 포함해야 하고, 팩토리를 통해 생성 및 삭제하고, 모든 메소드를 위임하고 동시에 CFoo* 링크를 번역해야 합니다.<->privateContext 이리저리. 이것은 "수동 일몰", 즉 상속을 위임에 의해 갑자기 교체하는 것입니다.
당신은 당신의 래퍼를 가지고 있고, 다른 하나는 그들의 래퍼를 가지고 있습니다. 질문은 달랐습니다. MQL4보다 더 편리한 래퍼를 만들 수 있습니까?
옵션이 많이 없는거 같은데..
개인적으로 특정 플랫폼의 특성과 전문가의 논리를 분리하기 위해 크로스 플랫폼 전용 래퍼가 필요합니다.
물론 리소스와 많은 디버깅 시간으로 OOP의 아름다움에 대한 비용을 지불해야 합니다. OOP는 편리한 텍스트 래퍼로 또는 런타임 환경을 초기화할 때 최소한의 사용으로만 의미가 있습니다. 본질적으로 OOP 는 순전히 Microsoft에서 프로그래머의 작업 시간 비용을 늘리고 고급 장비의 구매를 촉진하기 위한 마케팅이었습니다. 게다가 그들 자신은 바보가 아니며 모든 소프트웨어를 C와 어셈블러로 작성합니다.
글쎄, 당신은 몽상가이지만 ...
글쎄, 당신은 몽상가이지만 ...
라이코 뜨개질 주제에 대해 의미있는 말을 할 수 있습니까?
다시 마주했다...
MQL에서는 프로토타입에서 메소드 구현을 분리하는 것이 불가능하며 사용자(구매자, 테스터, 친구/동지)에게 별도의 *.mqh 파일과 별도의 *.ex4 파일(유추 *.h 및 .obj/lib/dll(C++의 경우)
다시 마주했다...
MQL에서는 프로토타입에서 메소드 구현을 분리하는 것이 불가능하며 사용자(구매자, 테스터, 친구/동지)에게 별도의 *.mqh 파일과 별도의 *.ex4 파일(유추 *.h 및 .obj/lib/dll(C++의 경우)
작업에 대해 더 많이 들을 수 있습니까? 다소 비뚤어진 것처럼 보이지만 순수 인터페이스를 반환하는 가져온 팩토리와 함께 헤더를 제공할 수 있으며 전체 구현은 ex4 내부에 고정되어 있습니다.
작업에 대해 더 많이 들을 수 있습니까? 다소 비뚤어진 것처럼 보이지만 순수 인터페이스를 반환하는 가져온 팩토리와 함께 헤더를 제공할 수 있으며 전체 구현은 ex4 내부에 고정되어 있습니다.
작업은 사용자에게 최소한의 제스처로 클래스 라이브러리를 제공하는 것입니다. mqh에는 클래스가 설명되어 있고 ex4에는 구현되어 있습니다.
이 날의 유일한 선택은 이 개그를 우회하기 위해 목발로 텍스트의 어둠을 당기는 것입니다.
ex4에서 CFoo 구현을 제거하는 짧고 편리한 방법을 알고 있다면 레시피를 공유하십시오.
class CFoo {
public:
CFoo(); //default
CFoo(const CFoo orig); // copy
~CFoo();
bool Set(string key,CFoo & link);
CFoo *Get(string key);
bool Clear(string key);
};
작업은 사용자에게 최소한의 제스처로 클래스 라이브러리를 제공하는 것입니다. mqh에는 클래스가 설명되어 있고 ex4에는 구현되어 있습니다.
이 날의 유일한 선택은 이 개그를 우회하기 위해 목발로 텍스트의 어둠을 당기는 것입니다.
ex4에서 CFoo 구현을 제거하는 짧고 편리한 방법을 알고 있다면 레시피를 공유하십시오.
class CFoo {
public:
CFoo(); //default
CFoo(const CFoo orig); // copy
~CFoo();
bool Set(string key,CFoo & link);
CFoo *Get(string key);
bool Clear(string key);
};
글쎄, 나는 이미 방법을 썼습니다 - 왜 작동하지 않습니까? 헤더 파일에 기술된 추상 클래스(인터페이스)를 반환 하는 팩토리 메서드 또는 함수를 만듭니다. 모든 구현이 숨겨져 있습니다. 예를 들어 내 블로그 에서 즉석에서 전문가 최적화 라이브러리 (영문)에 대한 실제 예를 찾을 수 있습니다.
글쎄, 나는 이미 방법을 썼습니다 - 왜 작동하지 않습니까? 헤더 파일에 기술된 추상 클래스(인터페이스)를 반환 하는 팩토리 메서드 또는 함수를 만듭니다. 모든 구현이 숨겨져 있습니다. 예를 들어 내 블로그 에서 즉석에서 전문가 최적화 라이브러리 (영문)에 대한 실제 예를 찾을 수 있습니다.
소스를 배포하려고 합니다. 그리고 여기 위키에 대한 링크가 있으므로 모두가 알고 있습니다.
출처가 있는 위키가 아닌 링크가 롤링되지 않습니까? ;-)
출처가 있는 위키가 아닌 링크가 롤링되지 않습니까? ;-)
하지만 굴러가지 않습니다 :-)
나는 당신에게 말하고 있습니다 - 그것을 시도하십시오. 그것은 엄청난 양의 코드입니다. 인스턴스화된 클래스 "СFoo: public InterfaceCFoo"는 InterfaceCFoo *privateContext 필드(1:1 연결 만들기)를 포함해야 하고, 팩토리를 통해 생성 및 삭제하고, 모든 메소드를 위임하고 동시에 CFoo* 링크를 번역해야 합니다.<->privateContext 이리저리. 이것은 "수동 일몰", 즉 상속을 위임에 의해 갑자기 교체하는 것입니다.