OOP与程序化编程 - 页 26 1...192021222324252627282930313233...48 新评论 Georgiy Merts 2017.08.14 15:37 #251 没有什么可想的。OOP是一种机制，它允许我们将大量的检查和批准传递给编译器。然而，我们必须花费一些额外的努力来使用它。 但如果我们不需要所有这些检查和配合，使用OOP就没有意义了。 例如，我对使用多维数组 的图形内核工作持谨慎态度--因为它有太多目前不需要的不必要的实体。它们让人分心，并引发难以计算的错误。我将用一组对象来代替它，我将用简单紧凑的接口来访问这些对象。通过获得一个接口--我不必记住任何东西--接口本身限制了我，并防止我，例如，访问错误的字段或对象。在图形化内核阵列的情况下，这种处理是非常可能的。 也就是说，在一个区块收到一个接口的情况下，编译器本身会 "切断 "所有不必要的实体，防止用户犯错。但在图形化内核阵列的情况下，用户有很多不必要的信息，他/她很容易出错。 根据我的经验，我知道当编译器本身会跟踪我在当前块中不应该去的地方时，我会好得多。而用图形化的内核阵列--我必须记住这一点。我的系统的负值是正值的延伸。如果我在一个区块中突然需要超越当前任务的东西，用图形化的内核阵列就很容易了--你只要拿着需要的数据就可以工作了。但对于OOP接口，你要么在一个额外的接口中请求必要的数据，要么（这更令人不快）修改现有的接口。 Nikolai Semko 2017.08.14 16:10 #252 George Merts:没有什么可想的。OOP是一种机制，它允许我们将大量的检查和批准传递给编译器。然而，我们必须花费一些额外的努力来使用它。 但如果我们不需要所有这些检查和配合--OOP就没有意义了。但为什么要把它简化得这么厉害？那么清晰度和可读性呢？以及错误检测和纠正的简单性？而便携性呢？和升级的便利性？等等，....。 Реter Konow 2017.08.14 16:28 #253 Nikolai Semko: 好吧，那么主题听起来应该有所不同。诸如："一个新的编程工具包 "或 "一个新的编程范式"......。 如果你真的创造了比OOP更酷的东西，那么当你成名时，你会给你的签名吗？没问题!不遗余力地为你的朋友签名。))))你在开玩笑，但在我的想象中，我对这种做法的看法是这样的，这真是一个无奈的选择。看来，随着时间的推移，我将能够启动系统的自我完善机制。如果我做一个逻辑内核，并让它随机地产生不同的机制。然后做一些选择，选择合适的就可以了。然后把它们磨碎一点...由于内核的存在，可以做一些不可思议的事情。 Maxim Kuznetsov 2017.08.14 16:31 #254 Nikolai Semko: 为什么要把事情简化得这么厉害。清晰度和可读性呢？以及错误检测和纠正的难易程度？便携性如何？和升级的便利性？等等，....。漂亮的横幅广告 :-)"购买我们的大象"。 所有这些理论都同样适用于OOP和非OOP以及FP和其他任何地方。 Реter Konow 2017.08.14 16:41 #255 George Merts:没有什么可想的。OOP是一种机制，它允许我们将大量的检查和批准传递给编译器。然而，我们必须花费一些额外的努力来使用它。 但如果我们不需要所有这些检查和配合，使用OOP就没有意义了。 例如，我对使用多维数组 的图形内核工作持谨慎态度--因为它有太多目前不需要的不必要的实体。它们让人分心，并引发难以计算的错误。我将用一组对象来代替它，我将用简单紧凑的接口来访问这些对象。通过获得一个接口--我不必记住任何东西--接口本身限制了我，并防止我，例如，访问错误的字段或对象。在图形化内核阵列的情况下，这种处理是非常可能的。 也就是说，在一个区块收到一个接口的情况下，编译器本身会 "切断 "所有不必要的实体，防止用户犯错。但在图形化内核阵列的情况下，用户有很多不必要的信息，他/她很容易出错。 根据我的经验，当编译器本身会跟踪我在当前块中不应该篡改的东西时，我的情况会好很多。而用图形化的内核阵列--我必须记住这一点。我的系统的负值是正值的延伸。如果我在一个区块中突然需要超越当前任务的东西，用图形化的内核阵列就很容易了--你只要拿着需要的数据就可以工作了。但对于OOP接口，你要么在一个额外的接口中请求必要的数据，要么（这更令人不快）修改现有的接口。 你认为内核中存在一些不必要的东西是错误的。而且很容易记住它的实体，因为它们通过定义被披上了人类语言的外衣。所有的东西都收集在那里，但这些内容有一个明确和不变的顺序。对象、窗口和元素的属性可以在程序的任何时候直接访问。你可以用循环中的内核做什么奇迹呢？ Georgiy Merts 2017.08.14 17:44 #256 Реter Konow: 你认为内核里有什么额外的东西是完全错误的。而记住它的实体是非常容易的，因为它们是通过定义披上了人类语言的外衣。所有的东西都收集在那里，但这些内容有一个明确和不变的顺序。对象、窗口和元素的属性可以在程序的任何时候直接访问。由于循环中的内核，你可以做什么奇迹...。我没有说 "内核是多余的"，我说的是 "目前没有必要"。如果我正在处理一个图线 - 我不应该能够访问窗口属性。 只是所有这些属性都可以在程序的任何地方直接访问，这是你们的方法的主要缺点。在程序的任何地方，只有那些在这个时间点上需要的元素才应该被访问。其他一切都应该是不可用的。这--使你能够自动避免许多错误。 在我看来，所有的 "由于整个内核的可访问性而产生的奇迹 "是难以发现的错误和理解代码问题的潜在来源。人们应尽量避免所有这些伎俩。 这种方法让我想起了非常愚蠢的任务，当指针、增量和引用被写在一行中，乱七八糟，从语言的角度看也许是正确的，但根本无法阅读。我在上面引用了我自己的函数，它看起来也绝对疯狂，但我想在这种情况下，紧凑性更重要。 СанСаныч Фоменко 2017.08.14 17:48 #257 Nikolai Semko: 那么，为什么要把它简化得这么厉害呢？而清晰性和可读性呢？以及检测和纠正错误的难易程度？而便携性呢？和升级的便利性？等等，....。太棒了!1.在开放之前，我们都是用特别复杂的工具从定制的部件上建造一切。2.在OOP之前，程序是一种特别混合的混合物3.在OOP之前，我们没有听说过数据和代码的本地化，这让我们的维护工作变得非常痛苦。4.同一程序的不同部分之间的数据保护是一场噩梦!5.在OOP之前，从来没有人扩展过系统。这是一次彻底的失败。我坐在那里想，也许这非常OOP是从我身上长出来的，因为我早在70年代末就应用了这一切，还有其他许多与编程文化有关的东西。 Реter Konow 2017.08.14 18:02 #258 George Merts:我没有说 "内核里有一些不必要的东西"，我说的是 "目前不必要"。如果我正在处理一个图线 - 我不应该能够访问窗口属性。 只是所有这些属性都可以在程序的任何地方直接访问，这是你们的方法的主要缺点。在程序的任何地方，只有那些在这个时间点上需要的元素才应该被访问。其他一切都应该是不可用的。这--使你能够自动避免许多错误。 在我看来，所有的 "由于整个内核的可访问性而产生的奇迹 "是难以发现的错误和理解代码问题的潜在来源。人们应尽量避免所有这些伎俩。 这种方法让我想起了最愚蠢的任务，当指针、增量和引用被写在一行中，乱七八糟，从语言的角度看可能是正确的，但绝对无法阅读。我在上面引用了我自己的函数，它看起来也绝对疯狂，但我想在这种情况下，紧凑性更重要。 你是根据你的经验，基于一时的理论概念来推理内核，这与你所谈论的技术毫无关系。因此，在访问方面存在一些问题，记住实体...我是从这项技术的实际经验来推理的，我说的是在访问或限制方面不存在这样的问题。老实说，我根本不知道你在说什么访问问题。没有这样的问题，也从来没有过这样的问题。请详细说明你指的是什么访问问题。如果会造成错误，你为什么认为必须限制访问？这对我来说是件新鲜事。在程序代码中直接访问一个全局数组，会不会本身就造成难以发现的错误？ Georgiy Merts 2017.08.14 18:14 #259 Реter Konow:你是根据你的经验，基于直接的理论概念来谈论内核，这与你所谈论的技术毫无关系。因此，在访问方面存在一些问题，记住实体...我是从这项技术的实际经验来推理的，我说的是在访问或限制方面不存在这样的问题。老实说，我根本不知道你在说什么访问问题。不存在也从来没有过这样的困难。当你说 "一切都可以从任何地方进入 "时，你的 "没有问题 "是什么意思？ 这就是主要问题 !它不应该被访问 ! 重点是将访问控制的任务转移到编译器上。一切都是开放的，由程序员控制访问。 没有任何并发症，因为你记得一切。你现在已经习惯了。 好吧，最终你会发现你的内存开始失效，然后你会感激编译器控制访问的能力。我不记得了。而且我怀疑大多数人也会定期忘记几个月前写的东西是如何运作的。正是在这种情况下，通道的划定成为一种福音。 比方说，如果你在负责下订单的区块内--你只有下订单的能力。而且你没有绘制图表的能力。如果你在一个负责绘制图表的区块中，你不能从那里下订单。这大大简化了工作。而当在绘制图表的 功能中，你突然看到一个下订单的请求，你将不得不在很长一段时间内记住你为什么这样做。如果有一个详细的评论，解释为什么做出这个决定，那就更好了......但如果将订单放在一个单一的、专门的区块中，效果会更好。 Реter Konow 2017.08.14 18:25 #260 George Merts:如果你说 "一切都可以从任何地方获得"，怎么会有 "没有问题"？ 这就是主要问题 !它必须不能被访问 ! 关键是要把访问控制的任务转移给编译器。一切都是开放的，由程序员控制访问。 没有任何并发症，因为你记得一切。你现在已经习惯了。 好吧，最终你会发现你的内存开始失效，然后你会感激编译器控制访问的能力。我不记得了。而且我怀疑大多数人也会定期忘记几个月前写的东西是如何运作的。正是在这些情况下，访问控制成为一种福音。 说，如果你在负责下订单的区块里面--你只有下订单的能力。而且你没有绘制图表的能力。如果你在一个负责绘制图表的区块中，你不能从那里下订单。这大大简化了工作。而当在绘制图表的功能中，你突然看到一个下订单的请求，你将不得不在很长一段时间内记住你为什么这样做。如果有一个详细的评论，解释为什么做出这个决定，那就更好了......但如果将订单放在一个单一的、专门的区块中，效果会更好。 在函数式程序设计中，你描述的访问问题并不存在。如果没有函数的重载，没有字段和对象，没有指针等等，当你只有一个内存用于所有全局变量，你可以从任何地方访问，你怎么能调用错误的函数呢？可能会发生什么样的访问错误？而且，要记住所有的东西就容易多了。 1...192021222324252627282930313233...48 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
没有什么可想的。
OOP是一种机制，它允许我们将大量的检查和批准传递给编译器。然而，我们必须花费一些额外的努力来使用它。
但如果我们不需要所有这些检查和配合，使用OOP就没有意义了。
例如，我对使用多维数组 的图形内核工作持谨慎态度--因为它有太多目前不需要的不必要的实体。它们让人分心，并引发难以计算的错误。我将用一组对象来代替它，我将用简单紧凑的接口来访问这些对象。通过获得一个接口--我不必记住任何东西--接口本身限制了我，并防止我，例如，访问错误的字段或对象。在图形化内核阵列的情况下，这种处理是非常可能的。
也就是说，在一个区块收到一个接口的情况下，编译器本身会 "切断 "所有不必要的实体，防止用户犯错。但在图形化内核阵列的情况下，用户有很多不必要的信息，他/她很容易出错。
根据我的经验，我知道当编译器本身会跟踪我在当前块中不应该去的地方时，我会好得多。而用图形化的内核阵列--我必须记住这一点。我的系统的负值是正值的延伸。如果我在一个区块中突然需要超越当前任务的东西，用图形化的内核阵列就很容易了--你只要拿着需要的数据就可以工作了。但对于OOP接口，你要么在一个额外的接口中请求必要的数据，要么（这更令人不快）修改现有的接口。
没有什么可想的。
OOP是一种机制，它允许我们将大量的检查和批准传递给编译器。然而，我们必须花费一些额外的努力来使用它。
但如果我们不需要所有这些检查和配合--OOP就没有意义了。
但为什么要把它简化得这么厉害？那么清晰度和可读性呢？以及错误检测和纠正的简单性？而便携性呢？和升级的便利性？等等，....。
好吧，那么主题听起来应该有所不同。诸如："一个新的编程工具包 "或 "一个新的编程范式"......。
如果你真的创造了比OOP更酷的东西，那么当你成名时，你会给你的签名吗？
没问题!不遗余力地为你的朋友签名。))))
你在开玩笑，但在我的想象中，我对这种做法的看法是这样的，这真是一个无奈的选择。看来，随着时间的推移，我将能够启动系统的自我完善机制。如果我做一个逻辑内核，并让它随机地产生不同的机制。然后做一些选择，选择合适的就可以了。然后把它们磨碎一点...由于内核的存在，可以做一些不可思议的事情。
为什么要把事情简化得这么厉害。清晰度和可读性呢？以及错误检测和纠正的难易程度？便携性如何？和升级的便利性？等等，....。
漂亮的横幅广告 :-)"购买我们的大象"。
所有这些理论都同样适用于OOP和非OOP以及FP和其他任何地方。
没有什么可想的。
OOP是一种机制，它允许我们将大量的检查和批准传递给编译器。然而，我们必须花费一些额外的努力来使用它。
但如果我们不需要所有这些检查和配合，使用OOP就没有意义了。
例如，我对使用多维数组 的图形内核工作持谨慎态度--因为它有太多目前不需要的不必要的实体。它们让人分心，并引发难以计算的错误。我将用一组对象来代替它，我将用简单紧凑的接口来访问这些对象。通过获得一个接口--我不必记住任何东西--接口本身限制了我，并防止我，例如，访问错误的字段或对象。在图形化内核阵列的情况下，这种处理是非常可能的。
也就是说，在一个区块收到一个接口的情况下，编译器本身会 "切断 "所有不必要的实体，防止用户犯错。但在图形化内核阵列的情况下，用户有很多不必要的信息，他/她很容易出错。
根据我的经验，当编译器本身会跟踪我在当前块中不应该篡改的东西时，我的情况会好很多。而用图形化的内核阵列--我必须记住这一点。我的系统的负值是正值的延伸。如果我在一个区块中突然需要超越当前任务的东西，用图形化的内核阵列就很容易了--你只要拿着需要的数据就可以工作了。但对于OOP接口，你要么在一个额外的接口中请求必要的数据，要么（这更令人不快）修改现有的接口。
你认为内核中存在一些不必要的东西是错误的。而且很容易记住它的实体，因为它们通过定义被披上了人类语言的外衣。所有的东西都收集在那里，但这些内容有一个明确和不变的顺序。对象、窗口和元素的属性可以在程序的任何时候直接访问。你可以用循环中的内核做什么奇迹呢？
你认为内核里有什么额外的东西是完全错误的。而记住它的实体是非常容易的，因为它们是通过定义披上了人类语言的外衣。所有的东西都收集在那里，但这些内容有一个明确和不变的顺序。对象、窗口和元素的属性可以在程序的任何时候直接访问。由于循环中的内核，你可以做什么奇迹...。
我没有说 "内核是多余的"，我说的是 "目前没有必要"。如果我正在处理一个图线 - 我不应该能够访问窗口属性。
只是所有这些属性都可以在程序的任何地方直接访问，这是你们的方法的主要缺点。在程序的任何地方，只有那些在这个时间点上需要的元素才应该被访问。其他一切都应该是不可用的。这--使你能够自动避免许多错误。
在我看来，所有的 "由于整个内核的可访问性而产生的奇迹 "是难以发现的错误和理解代码问题的潜在来源。人们应尽量避免所有这些伎俩。
这种方法让我想起了非常愚蠢的任务，当指针、增量和引用被写在一行中，乱七八糟，从语言的角度看也许是正确的，但根本无法阅读。我在上面引用了我自己的函数，它看起来也绝对疯狂，但我想在这种情况下，紧凑性更重要。
那么，为什么要把它简化得这么厉害呢？而清晰性和可读性呢？以及检测和纠正错误的难易程度？而便携性呢？和升级的便利性？等等，....。
太棒了!
1.在开放之前，我们都是用特别复杂的工具从定制的部件上建造一切。
2.在OOP之前，程序是一种特别混合的混合物
3.在OOP之前，我们没有听说过数据和代码的本地化，这让我们的维护工作变得非常痛苦。
4.同一程序的不同部分之间的数据保护是一场噩梦!
5.在OOP之前，从来没有人扩展过系统。
这是一次彻底的失败。
我坐在那里想，也许这非常OOP是从我身上长出来的，因为我早在70年代末就应用了这一切，还有其他许多与编程文化有关的东西。
我没有说 "内核里有一些不必要的东西"，我说的是 "目前不必要"。如果我正在处理一个图线 - 我不应该能够访问窗口属性。
只是所有这些属性都可以在程序的任何地方直接访问，这是你们的方法的主要缺点。在程序的任何地方，只有那些在这个时间点上需要的元素才应该被访问。其他一切都应该是不可用的。这--使你能够自动避免许多错误。
在我看来，所有的 "由于整个内核的可访问性而产生的奇迹 "是难以发现的错误和理解代码问题的潜在来源。人们应尽量避免所有这些伎俩。
这种方法让我想起了最愚蠢的任务，当指针、增量和引用被写在一行中，乱七八糟，从语言的角度看可能是正确的，但绝对无法阅读。我在上面引用了我自己的函数，它看起来也绝对疯狂，但我想在这种情况下，紧凑性更重要。
你是根据你的经验，基于一时的理论概念来推理内核，这与你所谈论的技术毫无关系。因此，在访问方面存在一些问题，记住实体...
我是从这项技术的实际经验来推理的，我说的是在访问或限制方面不存在这样的问题。老实说，我根本不知道你在说什么访问问题。没有这样的问题，也从来没有过这样的问题。
请详细说明你指的是什么访问问题。
如果会造成错误，你为什么认为必须限制访问？这对我来说是件新鲜事。
在程序代码中直接访问一个全局数组，会不会本身就造成难以发现的错误？
你是根据你的经验，基于直接的理论概念来谈论内核，这与你所谈论的技术毫无关系。因此，在访问方面存在一些问题，记住实体...
我是从这项技术的实际经验来推理的，我说的是在访问或限制方面不存在这样的问题。老实说，我根本不知道你在说什么访问问题。不存在也从来没有过这样的困难。
当你说 "一切都可以从任何地方进入 "时，你的 "没有问题 "是什么意思？
这就是主要问题 !它不应该被访问 !
重点是将访问控制的任务转移到编译器上。一切都是开放的，由程序员控制访问。
没有任何并发症，因为你记得一切。你现在已经习惯了。 好吧，最终你会发现你的内存开始失效，然后你会感激编译器控制访问的能力。我不记得了。而且我怀疑大多数人也会定期忘记几个月前写的东西是如何运作的。正是在这种情况下，通道的划定成为一种福音。
比方说，如果你在负责下订单的区块内--你只有下订单的能力。而且你没有绘制图表的能力。如果你在一个负责绘制图表的区块中，你不能从那里下订单。这大大简化了工作。而当在绘制图表的 功能中，你突然看到一个下订单的请求，你将不得不在很长一段时间内记住你为什么这样做。如果有一个详细的评论，解释为什么做出这个决定，那就更好了......但如果将订单放在一个单一的、专门的区块中，效果会更好。
如果你说 "一切都可以从任何地方获得"，怎么会有 "没有问题"？
这就是主要问题 !它必须不能被访问 !
关键是要把访问控制的任务转移给编译器。一切都是开放的，由程序员控制访问。
没有任何并发症，因为你记得一切。你现在已经习惯了。 好吧，最终你会发现你的内存开始失效，然后你会感激编译器控制访问的能力。我不记得了。而且我怀疑大多数人也会定期忘记几个月前写的东西是如何运作的。正是在这些情况下，访问控制成为一种福音。
说，如果你在负责下订单的区块里面--你只有下订单的能力。而且你没有绘制图表的能力。如果你在一个负责绘制图表的区块中，你不能从那里下订单。这大大简化了工作。而当在绘制图表的功能中，你突然看到一个下订单的请求，你将不得不在很长一段时间内记住你为什么这样做。如果有一个详细的评论，解释为什么做出这个决定，那就更好了......但如果将订单放在一个单一的、专门的区块中，效果会更好。