MQL5中的OOP问题 - 页 23

新评论
 
Vladimir Simakov:
我今晚会给你看。现在从我的手机上。

认可

从接口中取消继承不是问题，你可以从基类中继承，但在我看来，代码中会出现混乱--会更难理解哪个方法会被调用，用这种代码结构--"OOP模式--行为模式--策略"。

我总是和保证每个策略中都有一个构造函数，似乎这些构造函数还不需要......但我要留下这种可能性，它不是多余的

ZS：所有策略的基类本身也很紧凑，关于这一点。

class CStrategy: public IStrategy
{
protected:
   SSettingsForOrder  m_setting;
   COrder *m_order;
   void RunStrategy();
   double CalcLot();
   double GetPrice(); 
};

到目前为止，我喜欢代码结构的可读性和逻辑性，而 "在所有这些东西中 "最重要的是制作某种原型，这将允许快速添加策略本身并测试它们。

我已经在原则上写好了一切，但我不喜欢这些代码--我以程序化风格的服务功能（开单、手数计算等）的形式写的，然后我写了带有逻辑和调用这些服务功能的小类，并决定使其尽可能好）））。

 
Igor Makanu:

认可

从接口中取消继承不是问题，你可以从基类中继承，但在我看来，代码中会出现混乱--会更难理解哪个方法会被调用，用这种代码结构--"OOP模式--行为模式--策略"。

我总是和保证每个策略中都有一个构造函数，似乎这些构造函数还不需要......但我要留下这种可能性，它不是多余的

ZS：所有策略的基类本身也很紧凑，关于这一点。

到目前为止，我喜欢代码结构的可读性和逻辑性，而 "在所有这些手势中 "最重要的是做出某种原型，这将允许快速添加策略本身并测试它们。

我已经在原则上写好了一切，但我不喜欢这些代码--我以程序化的方式写了服务功能（打开一个订单，计算手数等），然后我写了带有逻辑和调用这些服务功能的小类，并决定让它尽可能的好）））。

//+------------------------------------------------------------------+
class CStrategy
{
protected:
   int x;
public:
   CStrategy(int _x):x(_x){}
   virtual void 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);
//+------------------------------------------------------------------+
void OnStart()
{  c1.GetStrategy();
   c2.GetStrategy(); }

这对我来说听起来更好。

 
Vladimir Simakov:

对我来说，这样看起来更好。

基本上是一样的，但不是按书上说的!))))

ZS：反正我已经把接口拧上了，随它去吧，纯属摆设。

 
Igor Makanu:

基本上是一样的，但不是按书上说的!))))

ZS：反正我已经栓上了接口，随它去吧，纯粹是做做样子。

只是在专业人员的风格中））））。
 
Vladimir Simakov:
只是在风格上有加分。））））。

没有多少人使用C#，或者说所有的应用程序员都转移到了C#，只有大型软件开发商使用C#。

在C#中所有的例子都是通过接口来实现的，所以很明显它们是无用的 ....我不希望陷入咆哮，但你可以在没有界面的情况下写出一切，概念、风格......。但概念、风格和其他脑中的迷雾告诉我，微软以前在C#中就是这样写例子的--只要坐下来，也这样写就可以了。

)))

 
Igor Makanu:

没有多少人使用C#，或者说所有的应用程序员都转移到了C#，只有大型软件开发商使用C#。

在C#中所有的例子都是通过接口来实现的，所以很明显它们是无用的 ....我不希望陷入咆哮，但你可以在没有接口的情况下写出一切，概念、风格......。但概念、风格和其他脑中的迷雾告诉我，微软以前在C#中就是这样写例子的--只要坐下来，也这样写就可以了。

)))

移动是因为在.NET下不方便写优点，而Sharp最初是作为dotnet的语言设计的。这是我的个人观点，起初我在.NET上写了pluses，感觉很笨拙。

虽然......他们为新的专业人员增加了很多东西，也许它更有趣。

 
Alexey Volchanskiy:

我们转换是因为pluses不方便在.NET上编写，而Sharp最初是作为dotnet的语言开发的。这是我的主观意见，一旦我在.NET下用pluses写作，我就会留下笨拙的印象。

虽然......他们为新的专业人员增加了很多东西，也许它更有趣。

我现在只是在为一个任务写windows form，摸到了c++/cli，决定不用它，印上c#。
 
Vladimir Simakov:
我现在只是在为一个任务写windows form，碰了一下c++/cli，决定忘掉它，打印c#。

是的，它在锐利度上是一个数量级的简单。而速度几乎是一样的，这是在没有悬崖的情况下，职业选手赢了一个半系数。

 
Vladimir Simakov:
我现在只是在为一个任务写一个windows表格，摸到了c++/cli，决定不用它，印上c#。

我试图在年初的时候接触到cli ...我满意了2天，谁做的这个cli的不人道的逻辑 - 语法复杂，一切都不方便，有例子的信息很少，imho或纯C++或C# - 谷歌所有的愿望，语法是明确的 - 作为一个结果，你采取和写入

 
Igor Makanu:

我试图在年初的时候接触到cli ...语法复杂，一切都不方便，有例子的信息很少，我认为--要么是纯C++，要么是C#--所有的欲望都是在网上搜索的，语法很清楚--最后你得到了，你就写了

夏普诞生于2000年左右，当时正处于起步阶段，但利好因素占了上风，所以他们用Dotnet为C++搭起了普及的桥梁。 顺便说一句，夏普是由Delphi和C++Builder的开发者创建的，我当时就想知道有多少共同的概念。采取相同的属性，事件。

1...161718192021222324252627282930...96
新评论