OOP代码能做什么，而程序性代码不能？
OOP的设计是为了像自然界的人一样工作和思考，让我们想象一下，如果我们想开发一个战争游戏，我们有很多类型的车辆，有很多技能的士兵和有很多规格的武器。
开发这种没有OOP的游戏对开发者来说是一种痛苦，因为他要跟踪所有这些类型的对象并很好地管理数据结构和内存，而且模拟OOP的特性如继承也很困难（尽管它可以做到），OOP使思考和开发变得更容易，也更容易编写阅读和调试代码。
有些时候，超过必要的OOP会使代码的理解和阅读变得不友好（我个人的观点），这是我不喜欢的。
你想如何建立一个包括继承树在内的重载虚函数的变通方法--这才是OOP最重要的部分？你似乎在谈论结构，而不是OOP。
OOP的设计是为了像自然界的人一样工作和思考，让我们想象一下，如果我们想开发一个战争游戏，我们有许多类型的车辆，有许多技能的士兵和有许多规格的武器。
开发这种没有OOP的游戏对开发者来说是一种痛苦，因为他们要跟踪所有这些类型的对象，并很好地管理数据结构和内存，而且模拟OOP的功能，如继承将是困难的（尽管它可以做到），OOP使思考和开发更容易，也更容易编写阅读和调试代码。
有些时候，超过必要的OOP会使代码的理解和阅读变得不友好（我个人的观点），这是我不喜欢的。
Alain Verleyen, 2016.05.22 14:03
我开设这个话题，是希望能收集到关于面向对象编程与程序化编程的优势的有用信息。
另外，这个话题是独立于语言的，因为mql4和mql5提供了相同的OOP语言（除了一些目前mql4还没有的新的高级功能）。
我不希望OOP的支持者和反对者之间发生 "战争"，所以这个话题将被严格控制，请不要浪费你和我的时间。
也请提供例子和代码来说明你的观点，而不是高深的理论或抽象的概念。
编辑：虽然这个话题是独立于语言的，但我们仍然在讨论交易和mql4/mql5，所以请不要用 "战争游戏 "或 "苹果和桔子 "的例子。
我是OOP的忠实粉丝--我甚至无法想象我会回到程序化的MQL。它更容易使程序变得更复杂。总之......MQL的问题是，新用户很难在这里开始。
- 内置的事件方法不是OO的。你必须钩住它们，这需要在根层声明监听对象。这种设计损害了基本的OOP原则之一。
- 缺少有共同模式的 "系统 "代码包。它阻止了在用户之间制作兼容的包，一个严肃的OOP编码者需要大量的时间来创建他的私有包。不支持的类名前缀（包名）只是一个小问题--当你无论如何都不能重用外部代码的时候。
所以我不建议在MQL中就开始学习OOP。编码者需要知道他需要什么来让它工作。
"如果......那么......否则...... "的语句应该可以完成工作。
呃，来吧；)并非如此；)如果本地的东西能以某种奇怪的方式完成工作，那么它就是指针，但在MQL中有限制。如果这样的话......代码就会变得很荒谬。如果你接受荒谬的代码作为这个问题的答案，那么它根本就过时了;)你同意荒谬是一个好的边界吗？来吧，说是吧，就一次，只是为了我的自我；)
对不起，我不会说是的......一个代码要么达到它的目标，要么没有，如果它是按照规范工作的，没有什么荒谬的。
问题是 "OOP能做什么，程序性不能做什么"？Stanislav说，OOP可以做与程序性相同的事情，但却是以一种 "更短、更漂亮 "的方式。我倾向于同意（除了更短的想法，但这并不重要）。
我开设这个话题是希望能收集关于面向对象编程与程序化编程的优势的有用信息。
另外，这个话题是独立于语言的，因为mql4和mql5提供了相同的OOP语言（除了一些新的高级功能 目前在mql4中还没有）。
我不希望OOP的支持者和反对者之间发生 "战争"，所以这个话题将被严格控制，请不要浪费你和我的时间。
也请提供例子和代码来说明你的观点，而不是高深的理论或抽象的概念。
EDIT：虽然这个话题是独立于语言的，但我们仍然在讨论交易和mql4/mql5，所以请不要用 "战争游戏 "或 "苹果和桔子 "的例子。