인터페이스에서 상속을 제거하는 것은 문제가 되지 않습니다. 기본 클래스에서 상속할 수 있지만 제 생각에는 코드에 혼란이 있을 것입니다. 어떤 메서드가 호출되는지 파악하는 것이 더 어려울 것이며 이러한 코드 구조에서도 - "OOP 패턴 - 행동 패턴 - 전략(전략)"
나는 항상 각 전략에 내 자신의 생성자가 있음을 보장합니다. 이러한 생성자는 아직 필요하지 않은 것 같습니다 ... 그러나 나는이 기회를 떠날 것입니다. 불필요한 것은 아닙니다
추신: 모든 전략에 대한 기본 클래스 자체도 다음과 같이 매우 컴팩트합니다.
class CStrategy: public IStrategy
{
protected :
SSettingsForOrder m_setting;
COrder *m_order;
void RunStrategy();
double CalcLot();
double GetPrice();
};
일반적으로 나는 당신의 예를 기다릴 것입니다. 일단 살펴보겠습니다. 지금은 코드 구조가 읽기 쉽고 논리적이며 "이 모든 제스처에서" 가장 중요한 것은 일종의 프로토타입을 만드는 것입니다. 전략 자체를 빠르게 추가하고 테스트할 수 있습니다.
원칙적으로 모든 것이 이미 작성되었지만 코드가 마음에 들지 않습니다. 절차적 스타일의 서비스 기능(주문 열기, 많이 계산 등)의 형태로 작성한 다음 다음과 같은 작은 클래스를 작성했습니다. 논리와 이러한 서비스 기능에 대한 호출이 있으므로 전체를 빗어보기로 결정했습니다.)))
인터페이스에서 상속을 제거하는 것은 문제가 되지 않습니다. 기본 클래스에서 상속할 수 있지만 제 생각에는 코드에 혼란이 있을 것입니다. 어떤 메서드가 호출되는지 파악하는 것이 더 어려울 것이며 이러한 코드 구조에서도 - "OOP 패턴 - 행동 패턴 - 전략(전략)"
나는 항상 각 전략에 내 자신의 생성자가 있음을 보장합니다. 이러한 생성자는 아직 필요하지 않은 것 같습니다 ... 그러나 나는이 기회를 떠날 것입니다. 불필요한 것은 아닙니다
추신: 모든 전략에 대한 기본 클래스 자체도 다음과 같이 매우 컴팩트합니다.
일반적으로 나는 당신의 예를 기다릴 것입니다. 일단 살펴보겠습니다. 지금은 코드 구조가 읽기 쉽고 논리적이며 "이 모든 제스처에서" 가장 중요한 것은 일종의 프로토타입을 만드는 것입니다. 전략 자체를 빠르게 추가하고 테스트할 수 있습니다.
원칙적으로 모든 것이 이미 작성되었지만 코드가 마음에 들지 않습니다. 절차적 스타일의 서비스 기능(주문 열기, 많이 계산 등)의 형태로 작성한 다음 다음과 같은 작은 클래스를 작성했습니다. 논리와 이러한 서비스 기능에 대한 호출이 있으므로 전체를 빗어보기로 결정했습니다.)))
//+------------------------------------------------------------------+class CStrategy
{
protected :
int x;
public :
CStrategy( int _x):x(_x){}
virtualvoid Algorithm()= 0 ;};
//+------------------------------------------------------------------+class CStrategy_01: public CStrategy
{
public :
CStrategy_01():CStrategy( 1 ) { Print ( __FUNCTION__ );}
void Algorithm() { Print ( __FUNCTION__ , ", x = " ,x); } };
//+------------------------------------------------------------------+class CStrategy_02: public CStrategy
{
public :
CStrategy_02():CStrategy( 2 ) { Print ( __FUNCTION__ );}
void Algorithm() { Print ( __FUNCTION__ , ", x = " ,x); } };
//+------------------------------------------------------------------+class Context
{
private :
CStrategy *s;
public :
Context(CStrategy* _strategy):s(_strategy) { Print ( __FUNCTION__ );}
~Context() { delete s; }
void GetStrategy() { s.Algorithm(); } };
//+------------------------------------------------------------------+
Context c1( new CStrategy_01);
Context c2( new CStrategy_02);
//+------------------------------------------------------------------+voidOnStart ()
{ c1.GetStrategy();
c2.GetStrategy(); }
그래서 소수의 사람들이 플러스에 앉아 있거나 오히려 C #의 모든 응용 프로그램 프로그래머가 이동하고 대형 소프트웨어 개발자만 플러스에 앉아 있습니다.
C#에서는 모든 예제가 인터페이스를 통해 이루어지며, 그 요점이 무엇인지 명확합니다. .... 선동을 일으키고 싶지는 않지만 일반적으로 모든 것이 인터페이스 없이 작성될 수 있지만 말하자면 개념, 스타일 ... 글쎄, 내 머리 속의 다른 안개는 여기에서 C# 예제에서 Microsoft에서 썼으므로 당신도 그렇게 앉아서 씁니다!
그래서 소수의 사람들이 플러스에 앉아 있거나 오히려 C #의 모든 응용 프로그램 프로그래머가 이동하고 대형 소프트웨어 개발자만 플러스에 앉아 있습니다.
C#에서는 모든 예제가 인터페이스를 통해 이루어지며, 그 요점이 무엇인지 명확합니다. .... 선동을 일으키고 싶지는 않지만 일반적으로 모든 것이 인터페이스 없이 작성될 수 있지만 말하자면 개념, 스타일 ... 글쎄, 내 머리 속의 다른 안개는 여기에서 C# 예제에서 Microsoft에서 썼으므로 당신도 그렇게 앉아서 씁니다!
)))
.NET에서는 프로에서 쓰기 불편하고 샤프는 원래 닷넷용 언어로 개발해서 옮겼습니다. 이것은 내 주관적인 의견이며 .NET에서 전문가에게 썼지만 서투른 인상이 남아 있습니다.
연초에 cli도 만지려고 했는데... 2일이 걸렸습니다, 이 cli를 만든 비인간적인 논리 - 구문이 까다롭고, 모든 것이 편리하지 않으며, 예가 포함된 정보가 거의 없습니다. IMHO 또는 순수한 C ++ 또는 C # - 모든 위시리스트가 검색되고 구문이 명확합니다.
샤프는 2000년쯤에 태어나 아주 유아기였고 플러스가 몰고 있었기 때문에 대중화를 위해 닷넷에 C++ 브릿지를 만들었습니다. 그건 그렇고, 샤프는 델파이와 C++빌더 개발자들이 만들었는데, 그 당시에는 공통적인 개념이 얼마나 많은지 매우 놀랐습니다. 동일한 속성, 이벤트를 가져옵니다.
오늘 밤에 보여드리겠습니다. 이제 전화에서.
확인
인터페이스에서 상속을 제거하는 것은 문제가 되지 않습니다. 기본 클래스에서 상속할 수 있지만 제 생각에는 코드에 혼란이 있을 것입니다. 어떤 메서드가 호출되는지 파악하는 것이 더 어려울 것이며 이러한 코드 구조에서도 - "OOP 패턴 - 행동 패턴 - 전략(전략)"
나는 항상 각 전략에 내 자신의 생성자가 있음을 보장합니다. 이러한 생성자는 아직 필요하지 않은 것 같습니다 ... 그러나 나는이 기회를 떠날 것입니다. 불필요한 것은 아닙니다
추신: 모든 전략에 대한 기본 클래스 자체도 다음과 같이 매우 컴팩트합니다.
일반적으로 나는 당신의 예를 기다릴 것입니다. 일단 살펴보겠습니다. 지금은 코드 구조가 읽기 쉽고 논리적이며 "이 모든 제스처에서" 가장 중요한 것은 일종의 프로토타입을 만드는 것입니다. 전략 자체를 빠르게 추가하고 테스트할 수 있습니다.
원칙적으로 모든 것이 이미 작성되었지만 코드가 마음에 들지 않습니다. 절차적 스타일의 서비스 기능(주문 열기, 많이 계산 등)의 형태로 작성한 다음 다음과 같은 작은 클래스를 작성했습니다. 논리와 이러한 서비스 기능에 대한 호출이 있으므로 전체를 빗어보기로 결정했습니다.)))
확인
인터페이스에서 상속을 제거하는 것은 문제가 되지 않습니다. 기본 클래스에서 상속할 수 있지만 제 생각에는 코드에 혼란이 있을 것입니다. 어떤 메서드가 호출되는지 파악하는 것이 더 어려울 것이며 이러한 코드 구조에서도 - "OOP 패턴 - 행동 패턴 - 전략(전략)"
나는 항상 각 전략에 내 자신의 생성자가 있음을 보장합니다. 이러한 생성자는 아직 필요하지 않은 것 같습니다 ... 그러나 나는이 기회를 떠날 것입니다. 불필요한 것은 아닙니다
추신: 모든 전략에 대한 기본 클래스 자체도 다음과 같이 매우 컴팩트합니다.
일반적으로 나는 당신의 예를 기다릴 것입니다. 일단 살펴보겠습니다. 지금은 코드 구조가 읽기 쉽고 논리적이며 "이 모든 제스처에서" 가장 중요한 것은 일종의 프로토타입을 만드는 것입니다. 전략 자체를 빠르게 추가하고 테스트할 수 있습니다.
원칙적으로 모든 것이 이미 작성되었지만 코드가 마음에 들지 않습니다. 절차적 스타일의 서비스 기능(주문 열기, 많이 계산 등)의 형태로 작성한 다음 다음과 같은 작은 클래스를 작성했습니다. 논리와 이러한 서비스 기능에 대한 호출이 있으므로 전체를 빗어보기로 결정했습니다.)))
내가 생각하는 한, 이것이 더 나을 것입니다.
나에 관해서는 이것이 더 나을 것입니다.
본질적으로 동일하지만 책에 따르면 아닙니다! ))))
추신: 여전히 인터페이스를 망쳤습니다. 순전히 과시용으로 두십시오!
본질적으로 동일하지만 책에 따르면 아닙니다! ))))
추신: 여전히 인터페이스를 망쳤습니다. 순전히 과시용으로 두십시오!
플러스 스타일로.)))
그래서 소수의 사람들이 플러스에 앉아 있거나 오히려 C #의 모든 응용 프로그램 프로그래머가 이동하고 대형 소프트웨어 개발자만 플러스에 앉아 있습니다.
C#에서는 모든 예제가 인터페이스를 통해 이루어지며, 그 요점이 무엇인지 명확합니다. .... 선동을 일으키고 싶지는 않지만 일반적으로 모든 것이 인터페이스 없이 작성될 수 있지만 말하자면 개념, 스타일 ... 글쎄, 내 머리 속의 다른 안개는 여기에서 C# 예제에서 Microsoft에서 썼으므로 당신도 그렇게 앉아서 씁니다!
)))
그래서 소수의 사람들이 플러스에 앉아 있거나 오히려 C #의 모든 응용 프로그램 프로그래머가 이동하고 대형 소프트웨어 개발자만 플러스에 앉아 있습니다.
C#에서는 모든 예제가 인터페이스를 통해 이루어지며, 그 요점이 무엇인지 명확합니다. .... 선동을 일으키고 싶지는 않지만 일반적으로 모든 것이 인터페이스 없이 작성될 수 있지만 말하자면 개념, 스타일 ... 글쎄, 내 머리 속의 다른 안개는 여기에서 C# 예제에서 Microsoft에서 썼으므로 당신도 그렇게 앉아서 씁니다!
)))
.NET에서는 프로에서 쓰기 불편하고 샤프는 원래 닷넷용 언어로 개발해서 옮겼습니다. 이것은 내 주관적인 의견이며 .NET에서 전문가에게 썼지만 서투른 인상이 남아 있습니다.
비록 ... 새로운 플러스에 많은 것들이 추가되었지만, 아마도 더 재미있어졌을 것입니다.
.NET에서는 프로에서 쓰기 불편하고 샤프는 원래 닷넷용 언어로 개발해서 옮겼습니다. 이것은 내 주관적인 의견이며 .NET에서 전문가에게 썼지만 서투른 인상이 남아 있습니다.
비록 ... 새로운 플러스에 많은 것들이 추가되었지만, 아마도 더 재미있어졌을 것입니다.
저는 이제 한 가지 작업을 위해 Windows 양식을 보고 C++/cli를 터치하고 잘 해결하고 C#을 인쇄했습니다.
예, 예리한 경우 훨씬 쉽습니다. 그리고 속도는 거의 동일하지만 cli가 없으면 플러스가 1.5 배 승리합니다.
저는 이제 한 가지 작업을 위해 Windows 양식을 보고 C++/cli를 터치하고 잘 해결하고 C#을 인쇄했습니다.
연초에 cli도 만지려고 했는데... 2일이 걸렸습니다, 이 cli를 만든 비인간적인 논리 - 구문이 까다롭고, 모든 것이 편리하지 않으며, 예가 포함된 정보가 거의 없습니다. IMHO 또는 순수 C ++ 또는 C # - 모든 위시리스트가 검색되고 구문이 명확합니다.
연초에 cli도 만지려고 했는데... 2일이 걸렸습니다, 이 cli를 만든 비인간적인 논리 - 구문이 까다롭고, 모든 것이 편리하지 않으며, 예가 포함된 정보가 거의 없습니다. IMHO 또는 순수한 C ++ 또는 C # - 모든 위시리스트가 검색되고 구문이 명확합니다.
샤프는 2000년쯤에 태어나 아주 유아기였고 플러스가 몰고 있었기 때문에 대중화를 위해 닷넷에 C++ 브릿지를 만들었습니다. 그건 그렇고, 샤프는 델파이와 C++빌더 개발자들이 만들었는데, 그 당시에는 공통적인 개념이 얼마나 많은지 매우 놀랐습니다. 동일한 속성, 이벤트를 가져옵니다.