在休息室谈论巴解组织的问题 - 页 10 1...34567891011121314151617...23 新评论 Georgiy Merts 2018.01.14 06:01 #91 Andrei:没有必要强求，但很明显，在程序化的形式下，代码的逻辑已经可以看到，不需要额外的手势，而雇佣的程序员的每一个手势都要向雇主收费。因此，如果雇主是聪明人，他不会被OOP所迷惑，但聪明的程序员可以利用他的低文化水平，扭曲一个关于渐进式OOP的故事，从他那里得到更多的钱。:)哈! 徒步出行有一个 "不费吹灰之力 "的逻辑，但由于某些原因，每个人都想乘坐交通工具。这已经到了白痴的地步--他们上了车，开车两公里到健身中心，然后在跑步机上 "绕 "五公里。 说到编程，在DOS中，一个窗口的创建只需将其写入视频缓冲区即可。但要在Windows中创建一个简单的窗口--你需要注册一个窗口类，创建它并运行一个消息处理的循环--但由于某些原因，每个人都会做这些非常 "额外的步骤"。 在这里也是如此。选择OOP--根本不是为了 "进步"，而是为了这种方法提供的好处，因为它最终对雇主来说更便宜。因为用程序化风格写的东西，你不能以同样的效率来维护它，而用OOP风格来写。 一个很好的例子--彼得-科诺夫的代码--一方面，相当正常的面向过程的代码，但另一方面，要用它工作，你必须始终牢记大量的系统结构信息，我个人不会承担这样的任务，即使是为了大钱。同时，用OOP风格编写的SB非常容易维护和改变。标准库的 TC模式中的对象的结构比Peter的代码要复杂得多，然而它更容易理解和修改。 所有关于 "没有额外工作的程序化风格 "的讨论，只在你需要写一个真正复杂的结构，特别是对其进行修改时才会出现。这就是为什么OOP被广泛使用--它对程序员来说更容易，对客户来说更便宜。虽然，在其中做一些相当简单的事情需要 "不必要的手势"。简单地说，没有人需要这种 "简单"，所有的人都需要 "复杂"，这最好是使用OOP来完成。P.S. 我还是不明白，你（让我们以 "你 "的名义）如何建议限制对函数的访问，这些函数在没有OOP访问修饰符的情况下不应该在任何地方使用？ Andrei01 2018.01.14 06:33 #92 George Merts:因为如果你用程序化风格写的东西，你将无法用同样的效率来维护它，而用OOP风格写的东西。 P.S. 我还是不明白，你（让我们用 "你 "来形容）如何建议限制对函数的访问，这些函数在没有OOP访问修饰符的情况下不应该被用于任何地方？ 不，不。这只是相反的方式。 这只是OOPeshe代码，很难维护和修改，因为其中有很多不同的曲折，以后再写一遍代码就容易了。事实上，有人说，OOP的目的是为了隐藏逻辑，所以他们把它隐藏起来，如果突然有必要揭开它，这是一项额外收费的服务。封装函数允许隐藏内部函数，但如果你突然觉得要添加这个内部函数，你可以把它隐藏在DLL中，或者把源代码隐藏在一个单独的文件中，并且把文件放在最远的目录中，这样即使你尝试也不会被发现，也许对于特别狂暴的程序员来说还有更多的选择。:) Georgiy Merts 2018.01.14 08:34 #93 Andrei:不，不是的。这只是相反的方式。 OOP代码同样难以维护和修改，因为那里的逻辑被隐藏了很多不同的技巧，这样就更容易重写代码了。事实上，有人说OOP的目的是为了隐藏逻辑，所以他们把逻辑隐藏起来了，如果突然需要揭开它，这是一种额外收费的服务。封装函数允许你隐藏内部函数，但如果你突然想添加这个内部函数做什么，你可以把它隐藏在DLL中，或把源代码隐藏在一个单独的文件中，并把文件放在最远的目录中，这样顶多是渴望它不能被发现，也许对于特别愤怒的程序员还有选择。:)如果逻辑被隐藏，为什么会 "难以修改"？ 这就是逻辑被隐藏的原因，以防止你在不能修改的地方修改。 只是在程序性方法中，你想改变一些东西，改变了它，然后你不明白为什么它不工作（或者更糟糕的是--有时你得到无法理解的错误）。而在OOP方法中，你想改变它--而你没有任何机会接触到类的内部结构。而如果没有访问，这意味着它是有原因的，那里有一些棘手的东西，一些隐性的使用条件。尊敬的是，如果你想改变一些东西，你可以采取那个类，继承它自己的类，在那里改变你需要的东西，因为你已经可以访问子类中的保护方法。 而且，即使你继承了它，你也可能偶然发现一个私有方法或字段，即使在子代中也是不可用的，再一次，出于某种原因，它意味着这个字段即使在子代中也不打算被改变。 谈到 "隐藏在DLL中"--问题是，你只能在DLL中隐藏所有的东西。不是物体的一部分。这就是访问修改器 的作用，只隐藏物体的一部分。这就是为什么一切都在构思之中--允许程序员在程序的每个地方只访问他所需要的东西，而没有任何 "来自上面 "的东西--这允许不担心他可能意外地改变他所需要的东西，但可以改变允许修改的部分。那么DLL的意义何在？打开DLL代码--那么整个代码被打开，而不是部分。关闭--同样，所有的通道都被关闭。 我不知道如何在不使用私有-保护-公共部分的情况下以程序化的方式限制访问。而这种限制对我帮助很大。 Alexey Volchanskiy 2018.01.14 09:11 #94 George Merts:如果逻辑是隐藏的，为什么会 "难以修改"？ 逻辑是隐藏的，所以你不能修改任何你不能修改的地方。 只是在程序性方法中，你想改变一些东西，改变了它，然后你不明白为什么它不工作（或者更糟糕的是--有时你得到无法理解的错误）。而在OOP方法中，你想改变它--而你没有任何机会接触到类的内部结构。而如果没有访问，这意味着它是有原因的，那里有一些棘手的东西，一些隐性的使用条件。尊敬的是，如果你想改变一些东西，你可以采取那个类，继承它自己的类，在那里改变你需要的东西，因为你已经可以访问子类中的保护方法。 而且，即使你继承了它，你也可能偶然发现一个私有方法或字段，即使在子代中也是不可用的，再一次，出于某种原因，它意味着这个字段即使在子代中也不打算被改变。 谈到 "隐藏在DLL中"--问题是，你只能在DLL中隐藏所有的东西。不是物体的一部分。这就是访问修改器 的作用，只隐藏物体的一部分。这就是为什么一切都在构思之中--允许程序员在程序的每个地方只访问他所需要的东西，而没有任何 "来自上面 "的东西--这允许不担心他可能不小心改变他所需要的东西，但可以改变允许修改的部分。那么DLL的意义何在？打开DLL代码--那么整个代码被打开，而不是部分。关闭它--同样，所有的访问都被关闭。 我不知道在不使用私有保护-公共部分的情况下，你如何能以程序性风格限制访问。而这种限制对我帮助很大。乔治，你又在打鼓了 ))))这毫无意义。 Georgiy Merts 2018.01.14 09:31 #95 Alexey Volchanskiy: 乔治，你又在拐弯抹角了 ))))这没有任何意义。也许，也许。 但你是一个兼职的卡萨诺瓦...而且我是一名兼职辅导员。我看到，"客户并没有失去"。所以我继续解释。如 "职业畸形"。 Alexey Volchanskiy 2018.01.14 10:14 #96 George Merts:也许，也许。 但你是兼职的卡萨诺瓦...而且我是一名兼职辅导员。我看到，"客户并没有失去"。所以，我一直在解释自己。如 "职业畸形"。 我已经受够了卡萨诺瓦家族。你编造了一个童话故事，并且自己相信它），就像一个孩子相信圣诞老人一样，看在上帝的份上。） fxsaber 2018.01.14 10:35 #97 Andrei:没有必要强求，但很明显，在程序化的形式下，代码的逻辑已经可以看到了，不需要额外的 手势，而雇佣的程序员的每一个手势都要花费雇主的钱。如果需要改变，上述程序代码中的手势数量需要更多。编写没有函数（程序）的代码是可能的。但编码最终不再是通过 "浇筑混凝土 "来写的，而是开始从 "砖头 "开始构建。因此出现了程序化编程。OOP是将整体工作分解为更简单的组件的另一个步骤。劳动分工，以及由此带来的任何东西的生产的输送，创造了工业革命，导致了人类的工业化。手工制作是 "不按程序写代码"。输送器是 "程序性代码编写"，输送器的许多元素都依赖于其他元素。也就是说，改变一个元素可能需要改变另一个元素。"OOP编程 "是一个减少元素之间依赖性的管道。也就是说，一个元素可以被另一个取代，而管道停止工作的可能性较小。能够将任何生产分解成独立的部分，输入标准，等等。- 是面向对象的制造（不是编程）。编程本身是生产的一个特例。OOP方法是一种生产任何东西的原则性方法。因此，谈论编程是非常狭窄的。OOP在出现在编程中之前就已经成功应用了。 Georgiy Merts 2018.01.14 10:42 #98 Alexey Volchanskiy: 我已经受够了卡萨诺瓦家族。你编造了一个童话故事，并且自己相信它，就像一个孩子相信圣诞老人一样，看在上帝的份上。）我很羡慕你，莱赫! 相当认真。好吧，给我留点艺术夸张的权利......。 Georgiy Merts 2018.01.14 10:44 #99 fxsaber:在上述程序中，身体动作的数量...О !说得好。 完全支持。 Andrei01 2018.01.14 10:54 #100 fxsaber:如果需要做出改变，上述程序代码中的身体努力量需要更大。原则上说，OOP中的身体力行量不能少，因为所有这些接口都是额外的开销，往往超过了编写逻辑本身的成本。而这是在任何函数都已经有了接口的情况下，即提出要做另一个对冲，这基本上是没有意义的。 同时，代码中的任何变化，无论是界面还是功能，都会变得更加复杂，因为一个是挂在另一个上的，这意味着我们在可能的bug数量和劳动强度上至少有四倍的增长......。这有点明显，不是吗？ 1...34567891011121314151617...23 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
没有必要强求，但很明显，在程序化的形式下，代码的逻辑已经可以看到，不需要额外的手势，而雇佣的程序员的每一个手势都要向雇主收费。因此，如果雇主是聪明人，他不会被OOP所迷惑，但聪明的程序员可以利用他的低文化水平，扭曲一个关于渐进式OOP的故事，从他那里得到更多的钱。:)
哈!
徒步出行有一个 "不费吹灰之力 "的逻辑，但由于某些原因，每个人都想乘坐交通工具。这已经到了白痴的地步--他们上了车，开车两公里到健身中心，然后在跑步机上 "绕 "五公里。
说到编程，在DOS中，一个窗口的创建只需将其写入视频缓冲区即可。但要在Windows中创建一个简单的窗口--你需要注册一个窗口类，创建它并运行一个消息处理的循环--但由于某些原因，每个人都会做这些非常 "额外的步骤"。
在这里也是如此。选择OOP--根本不是为了 "进步"，而是为了这种方法提供的好处，因为它最终对雇主来说更便宜。因为用程序化风格写的东西，你不能以同样的效率来维护它，而用OOP风格来写。
一个很好的例子--彼得-科诺夫的代码--一方面，相当正常的面向过程的代码，但另一方面，要用它工作，你必须始终牢记大量的系统结构信息，我个人不会承担这样的任务，即使是为了大钱。同时，用OOP风格编写的SB非常容易维护和改变。标准库的 TC模式中的对象的结构比Peter的代码要复杂得多，然而它更容易理解和修改。
所有关于 "没有额外工作的程序化风格 "的讨论，只在你需要写一个真正复杂的结构，特别是对其进行修改时才会出现。这就是为什么OOP被广泛使用--它对程序员来说更容易，对客户来说更便宜。虽然，在其中做一些相当简单的事情需要 "不必要的手势"。简单地说，没有人需要这种 "简单"，所有的人都需要 "复杂"，这最好是使用OOP来完成。
P.S. 我还是不明白，你（让我们以 "你 "的名义）如何建议限制对函数的访问，这些函数在没有OOP访问修饰符的情况下不应该在任何地方使用？
George Merts:
因为如果你用程序化风格写的东西，你将无法用同样的效率来维护它，而用OOP风格写的东西。
P.S. 我还是不明白，你（让我们用 "你 "来形容）如何建议限制对函数的访问，这些函数在没有OOP访问修饰符的情况下不应该被用于任何地方？不，不。这只是相反的方式。
这只是OOPeshe代码，很难维护和修改，因为其中有很多不同的曲折，以后再写一遍代码就容易了。事实上，有人说，OOP的目的是为了隐藏逻辑，所以他们把它隐藏起来，如果突然有必要揭开它，这是一项额外收费的服务。
封装函数允许隐藏内部函数，但如果你突然觉得要添加这个内部函数，你可以把它隐藏在DLL中，或者把源代码隐藏在一个单独的文件中，并且把文件放在最远的目录中，这样即使你尝试也不会被发现，也许对于特别狂暴的程序员来说还有更多的选择。:)
不，不是的。这只是相反的方式。
OOP代码同样难以维护和修改，因为那里的逻辑被隐藏了很多不同的技巧，这样就更容易重写代码了。事实上，有人说OOP的目的是为了隐藏逻辑，所以他们把逻辑隐藏起来了，如果突然需要揭开它，这是一种额外收费的服务。
封装函数允许你隐藏内部函数，但如果你突然想添加这个内部函数做什么，你可以把它隐藏在DLL中，或把源代码隐藏在一个单独的文件中，并把文件放在最远的目录中，这样顶多是渴望它不能被发现，也许对于特别愤怒的程序员还有选择。:)
如果逻辑被隐藏，为什么会 "难以修改"？ 这就是逻辑被隐藏的原因，以防止你在不能修改的地方修改。
只是在程序性方法中，你想改变一些东西，改变了它，然后你不明白为什么它不工作（或者更糟糕的是--有时你得到无法理解的错误）。而在OOP方法中，你想改变它--而你没有任何机会接触到类的内部结构。而如果没有访问，这意味着它是有原因的，那里有一些棘手的东西，一些隐性的使用条件。尊敬的是，如果你想改变一些东西，你可以采取那个类，继承它自己的类，在那里改变你需要的东西，因为你已经可以访问子类中的保护方法。
而且，即使你继承了它，你也可能偶然发现一个私有方法或字段，即使在子代中也是不可用的，再一次，出于某种原因，它意味着这个字段即使在子代中也不打算被改变。
谈到 "隐藏在DLL中"--问题是，你只能在DLL中隐藏所有的东西。不是物体的一部分。这就是访问修改器 的作用，只隐藏物体的一部分。这就是为什么一切都在构思之中--允许程序员在程序的每个地方只访问他所需要的东西，而没有任何 "来自上面 "的东西--这允许不担心他可能意外地改变他所需要的东西，但可以改变允许修改的部分。那么DLL的意义何在？打开DLL代码--那么整个代码被打开，而不是部分。关闭--同样，所有的通道都被关闭。
我不知道如何在不使用私有-保护-公共部分的情况下以程序化的方式限制访问。而这种限制对我帮助很大。
如果逻辑是隐藏的，为什么会 "难以修改"？ 逻辑是隐藏的，所以你不能修改任何你不能修改的地方。
只是在程序性方法中，你想改变一些东西，改变了它，然后你不明白为什么它不工作（或者更糟糕的是--有时你得到无法理解的错误）。而在OOP方法中，你想改变它--而你没有任何机会接触到类的内部结构。而如果没有访问，这意味着它是有原因的，那里有一些棘手的东西，一些隐性的使用条件。尊敬的是，如果你想改变一些东西，你可以采取那个类，继承它自己的类，在那里改变你需要的东西，因为你已经可以访问子类中的保护方法。
而且，即使你继承了它，你也可能偶然发现一个私有方法或字段，即使在子代中也是不可用的，再一次，出于某种原因，它意味着这个字段即使在子代中也不打算被改变。
谈到 "隐藏在DLL中"--问题是，你只能在DLL中隐藏所有的东西。不是物体的一部分。这就是访问修改器 的作用，只隐藏物体的一部分。这就是为什么一切都在构思之中--允许程序员在程序的每个地方只访问他所需要的东西，而没有任何 "来自上面 "的东西--这允许不担心他可能不小心改变他所需要的东西，但可以改变允许修改的部分。那么DLL的意义何在？打开DLL代码--那么整个代码被打开，而不是部分。关闭它--同样，所有的访问都被关闭。
我不知道在不使用私有保护-公共部分的情况下，你如何能以程序性风格限制访问。而这种限制对我帮助很大。
乔治，你又在打鼓了 ))))这毫无意义。
乔治，你又在拐弯抹角了 ))))这没有任何意义。
也许，也许。
但你是一个兼职的卡萨诺瓦...而且我是一名兼职辅导员。我看到，"客户并没有失去"。所以我继续解释。如 "职业畸形"。
也许，也许。
但你是兼职的卡萨诺瓦...而且我是一名兼职辅导员。我看到，"客户并没有失去"。所以，我一直在解释自己。如 "职业畸形"。
我已经受够了卡萨诺瓦家族。你编造了一个童话故事，并且自己相信它），就像一个孩子相信圣诞老人一样，看在上帝的份上。）
没有必要强求，但很明显，在程序化的形式下，代码的逻辑已经可以看到了，不需要额外的 手势，而雇佣的程序员的每一个手势都要花费雇主的钱。
如果需要改变，上述程序代码中的手势数量需要更多。
编写没有函数（程序）的代码是可能的。但编码最终不再是通过 "浇筑混凝土 "来写的，而是开始从 "砖头 "开始构建。因此出现了程序化编程。
OOP是将整体工作分解为更简单的组件的另一个步骤。
劳动分工，以及由此带来的任何东西的生产的输送，创造了工业革命，导致了人类的工业化。
手工制作是 "不按程序写代码"。
输送器是 "程序性代码编写"，输送器的许多元素都依赖于其他元素。也就是说，改变一个元素可能需要改变另一个元素。
"OOP编程 "是一个减少元素之间依赖性的管道。也就是说，一个元素可以被另一个取代，而管道停止工作的可能性较小。能够将任何生产分解成独立的部分，输入标准，等等。- 是面向对象的制造（不是编程）。
编程本身是生产的一个特例。OOP方法是一种生产任何东西的原则性方法。因此，谈论编程是非常狭窄的。OOP在出现在编程中之前就已经成功应用了。
我已经受够了卡萨诺瓦家族。你编造了一个童话故事，并且自己相信它，就像一个孩子相信圣诞老人一样，看在上帝的份上。）
我很羡慕你，莱赫!
相当认真。好吧，给我留点艺术夸张的权利......。
在上述程序中，身体动作的数量...
О !说得好。
完全支持。
如果需要做出改变，上述程序代码中的身体努力量需要更大。
原则上说，OOP中的身体力行量不能少，因为所有这些接口都是额外的开销，往往超过了编写逻辑本身的成本。而这是在任何函数都已经有了接口的情况下，即提出要做另一个对冲，这基本上是没有意义的。
同时，代码中的任何变化，无论是界面还是功能，都会变得更加复杂，因为一个是挂在另一个上的，这意味着我们在可能的bug数量和劳动强度上至少有四倍的增长......。这有点明显，不是吗？