给OOP专家的一个问题。 - 页 9

新评论
 
Roman:

在C++中，对OOP的理解不是一蹴而就的，我在理解了过程性方法后，大约一年半后开始接触OOP。

我也是如此--一点一点地......而完全理解是在4-5年之后（对一个普通人来说这很正常）。

 
Igor Makanu:


ZS: 我如何改变按钮的颜色？- 杀死以前的对象，并创建一个不同颜色的新按钮？- 以及如何获得按钮状态？- 如果是几百个按钮的颜色方案--再把它们全部杀掉，然后再创建其他的？）

这在MQ中是如何运作的？

class CButton : public CWndObj:

private:
   CChartObjectButton m_button;             // chart object
..
virtual bool      OnSetColor(void)             { return(m_button.Color(m_color));                }

class CChartObjectText : public CChartObject

class CChartObject : public CObject:

bool CChartObject::Color(const color new_color) const
  {
//--- check
   if(m_chart_id==-1)
      return(false);
//--- result
   return(ObjectSetInteger(m_chart_id,m_name,OBJPROP_COLOR,new_color));
  }

class CWndObj : public CWnd:

color             m_color;               // object color
...
bool CWndObj::Color(const color value)
  {
//--- save new value of parameter
   m_color=value;
//--- call virtual event handler
   return(OnSetColor());
  }


因此，在CButton类中 添加一个函数即可。

virtual bool      OnSetColor(uint clr)         { return(m_button.Color(clr));  }
 
Nikolai Semko:

那么这在MQ中是如何运作的呢？

class CButton : public CWndObj:

class CChartObjectText : public CChartObject

class CChartObject : public CObject:

class CWndObj : public CWnd:


所以你所要做的就是给CButton类 添加一个函数。

好吧，所有的OOP方法都是这样的，即使在MQL中也是如此--我看过源代码，即使在Delphi中，即使在VS中，代码结构和逻辑都是一样的。


听着，我的订阅里有这个频道，总的来说，我对作者的看法是积极的，甚至还有重复你视频的主题，这也是争端的开始。



而且还有一个我喜欢的频道。


视频中的观点在OOP方面是截然相反的


删除了我的帖子，讨论的时间比我计划的要长，我怀疑我是否会等待具体细节，讨论 "球形OOP "而没有实际用处，不是最好的主意。

 
Igor Makanu:

所有的OOP技术都是这样的，即使在MQL中也是如此--我看了SB的源代码，即使在Delphi中，即使在VS中--代码结构和逻辑总是相同的。


听着，我的订阅里有这个频道，总的来说，我对作者的看法是积极的，甚至还有重复你视频的主题，这也是争端的开始。


而且还有一个我喜欢的频道。


视频中的观点在OOP方面是截然相反的


删除了我的帖子，讨论的时间比我计划的要长，我怀疑我是否会等待具体细节，讨论 "球形OOP "而没有实际用途，不是最好的主意。

说实话，我自己也只是刚刚开始接触到OOP的概念。我更直观地同意Egor Bugaenko的观点，并基于我已有的一点经验。
此外，我从纯哲学的角度知道，复杂性往往会导致一个死胡同，所以我认为 "整体，由简单成分组成 "的方案比 "整体，由一个复杂成分组成 "更完美。
所以在看完这个视频后，我将尝试坚持以下的逻辑和范式：
如果在某些时候，似乎解决问题的唯一方法是通过繁琐的复杂化，那么是时候把它分解成更简单的元素。 如果看起来不可能，这意味着我们选择了一个错误的概念，必须改变它并重写整个代码。我认为这将在未来节省时间。

 

有许多变化。这一切都取决于你需要什么，以及你有什么想象力。比如说这个。

class A
  {
public:
                     A(void)  {    };
                    ~A(void)  {    };
  };
  
class B
  {
public:
                     B(void)  {    };
                    ~B(void)  {    };
  };

class C
  {
public:
                     C(void)  {    };
                    ~C(void)  {    };
  };

struct STest
  {
   A a[];
   B b[];
   C c[];
  } test[];
[删除]  
Igor Makanu:

删除了我的帖子，讨论的时间会比计划的要长。

彼得的主题是一个无情的元素，在它的路径上拉动一切）），这只是一个介绍，前面是 "核心-引擎-概念 "的出口，彼得在那里有更多的经验））。

 
Nikolai Semko:

因此，看完这段视频 后，我将尝试坚持以下逻辑和范式：
如果在某个时候，似乎解决问题的唯一方法是通过繁琐的复杂化，那么就应该把它分解成更简单的元素。 如果看起来不可能，这意味着我们选择了一个错误的概念，需要改变它并重写整个代码。我认为这将在未来节省时间。

在理论上这是可行的，在实践中--这取决于你将工作的行业，除了游戏开发，任何错误都会由游戏者的硬件或办公软件来补偿，错误并不关键--我们以后会修复或重写，有些领域你不能犯错，我在生产自动化领域工作，自动化不是灯泡，电力行业--电力涡轮。软件和自动化 "一车一车"--机架ACS、ACS、振动控制、操作员控制台，以及执行器的控制器和传感器，而且这一切都在一个复杂的工作中同时进行，任何概念上的错误--最好是紧急停止，最坏是--设备的破坏和财产损失。

这有什么意义呢？- 因为代码首先必须是有效的!多年来创造的所有东西都写在 "不正确的使用OOP "上，而创新者...好吧，坐下来喝杯啤酒，梦想一下人类的微软和谷歌是如何误入歧途的--这很酷！但到目前为止，还没有问责。

 
A100:

你是第一个给我写信的人（这说明你很关心），我当时正在回答 Alexey Viktorov 关于标准库的问题

这个问题是反问句。这不是很清楚吗？

 
Alexey Viktorov:

这个问题是反问句。这不是很清楚吗？

反问句包含一个明显的陈述--我不明白这个陈述是什么意思。你能解释一下吗？
 
A100:
一个反问句包含一个明显的陈述--我不明白这个陈述是什么。你能解释一下吗？

一个反问句绝不可能像任何问题一样包含断言。一个问题还是一个问题。这是同一个问题，但它不需要答案，也不期望有答案。一个无处不在的问题。

12345678910111213141516...55
新评论