OOP与程序化编程 - 页 36

新评论
 
George Merts:

1.没有到任何程度。盈利能力并不取决于AOP。

2.在我看来，是一个数量级的（十倍）。但OOP的主要收获是在代码支持方面。现在我可以非常迅速地找出我在一年或更久以前写的代码。我清楚地记得，我是如何理解我早期的ANSI C程序的，纯粹是程序化风格。这就更难了。


1.这是对OOP需求的主要回答。

2.这是一个团队的经验问题。我写了我需要的一切。几年前，我决定再写一些--一切都能读，没有问题。


从你的回答中，我明白了一件事：OOP是某种标准，它引入了编程的纪律，引入了统一性，在此基础上，最初的错误更少，最重要的也是最重要的是，它在原则上减少了修改的问题。但在认真遵守GOST、发展阶段、可记录性的情况下，也得到了同样的结果。

 
СанСаныч Фоменко:

我不明白为什么我在工作中从来没有遇到过这样的事情。为什么在一个不算大的项目中，会出现一个开发者的可变访问差异化问题？会有100个开发人员，每个人都在编写100个函数。理论上，它可以被发明出来。但实际上，编程发展到OOP已经有近40年了，堆积如山的代码已经被写出来了，我从来没有听说过这样的事情。

那么，在一开始，程序根本就是用代码写的。

OOP只是一种技术，它允许你更快地编写更复杂的程序，然后更有效地维护它们。

但这并不意味着OOP是一个万能的解决方案。我说，如果你有像Peter那样的内存，你根本不需要OOP--全局声明所有的东西，这就结束了，因为你记住了所有的东西，并且很容易避免碰撞或变量的混合。但是，我有更糟糕的记忆。还有划线--我非常喜欢用它。在过去的几年里，我非常喜欢修饰语 "const"--我以前很少使用它。现在我非常经常地使用它。只是为了只访问我需要的东西，而不是更多。因此，在不打算改变的地方，这种访问是只读的。

 

George Merts:

是的，的确，有些情况下，突然发现几乎不可能得到你需要的数据。它们隐藏在几个虚拟界面后面。然而，这种情况清楚地表明，该系统最初的设计是不正确的，它没有规定这种数据的传输。这种情况确实非常令人不快。我们要么匆忙地以附加接口的形式建立 "拐杖"，要么重组整个系统。 嗯......它促使程序员更仔细地思考系统结构。

如果程序员是一个预言家和千里眼，能提前看到所有必要的数据结构 的细节，为主要想法的所有可能的变体，那么按你的方式行事可能是有意义的。或者在最后阶段做，当所有的东西都已经工作了，代码也调试好了，不需要使用这些附加组件，但还是那句话，前提是没有什么需要改变和重新安排的......

 
СанСаныч Фоменко:

1.这是对OOP需求的主要回答。

2、这是一个团队的经验问题。我写了我需要的一切。几年前，我决定再写一些--一切都能读，没有问题。

从你的回答中，我明白了一件事：OOP是某种标准，它引入了编程的纪律，引入了统一性，在此基础上，最初的错误较少，最重要的是，修改过程中的问题从根本上减少。但在认真遵守GOST、发展阶段、可记录性的情况下，也得到了同样的结果。

1.没有。OOP不是一个确保盈利的工具。而且，你不能一边谈论OOP的必要性，一边看盈利能力。OOP是一种简化代码开发和维护的工具。

2.十年前的TC还在工作，这很酷。我不能这样生活，他们经常停止对我的工作，我不得不不断修改他们。而OOP在这方面对我有很大帮助。

而关于OOP-一些标准，是的，都是真的。而且，如果你保持交错和记录，确实可以得到同样的结果。但在我看来，这比OOP的情况下需要更多的努力。

 
George Merts:

一开始，程序是用代码编写的。

OOP只是一种技术，它允许你更快地编写更复杂的程序，然后更有效地维护它们。

但这并不意味着OOP是万能的。我说，如果你有像Peter那样的内存，你根本不需要OOP--全局声明所有的东西，然后就可以了，因为你记得所有的东西，而且很容易避免碰撞或变量的混合。但是，我有更糟糕的记忆。还有划线--我非常喜欢用它。在过去的几年里，我非常喜欢修饰语 "const"--我以前很少使用它。现在我非常经常地使用它。只是为了只访问我需要的东西，而不是更多。因此，在那些不打算改变的地方，这种访问是只读的。

起初，程序是用代码编写的。

我们不要把事情扭曲了，好吗？

OOP只是一种技术，它允许你更快地编写更复杂的程序，然后更有效地维护它们。

这是值得怀疑的，而且非常值得怀疑。

如果有好的设计文档，就能更快地编写和有效地维护程序。这个问题的回声可以在市场上找到，那里对TOR 给予了很大的关注。如果TOR是糟糕的，没有OOP会有帮助。

 
СанСаныч Фоменко:

具有良好的项目文件的方案的编写和维护更加迅速和有效。这个问题的回声可以在市场上找到，那里对TOR给予了很大的关注。如果TOR是糟糕的，没有OOP会有帮助。

问题是，程序文件和TOR是不同的东西。你把这两者混为一谈是非常奇怪的。现代程序实际上不需要文档--一切都在类的界面中呈现。
 
Andrei:

如果程序员是一个预言家和千里眼，能提前看到所有细节，看到所有可能的主旨实现的变体的必要数据结构，那么按照你的方式行事可能是有意义的。或者在最后阶段做，当所有的东西都已经工作了，代码也调试好了，不需要使用这些附加组件，但还是那句话，前提是没有什么需要改变和重新安排的......

好吧，我没有预见到通过接口传递重要信息的可能性的情况是很少的。但另一件事对我来说更重要--正如上面Igor所说的那样--每个类只对自己的变量负责，不可能 "搞乱 "其他类。因此，大多数问题在编译阶段就被切断了。
 
George Merts:

OOP只是一种技术，它允许你更快地编写更复杂的程序，然后更有效地维护它们。

如上所述，OOP的初衷并不是为了快速编写和调试代码，因为有许多附加的包装器、中间的上层结构和适配器...只有在最后阶段才有意义，因为所有的东西都在工作和调试，数据结构 已经获得了最终的形式......。也就是说，它是一个纯粹的外观程序，即包装准备好的代码，以便随后存储...

 
George Merts:
但另一件事对我来说更重要--伊戈尔在上面正确地说--每个类只对自己的变量负责，不可能从它那里 "进入 "别人的变量。因此，大多数问题在编译阶段就被切断了。

一个类只有内部变量，没有输入或输出变量...你在哪里看到过这样一个与外界没有接触、在自己的汁液中沸腾的物体在编程中的用途？

 
Ihor Herasko:
....现代程序实际上不需要文档--一切都在你手掌上的类接口中。

向元引解释一下：为什么他们要为终端、为语言写大量的手册，一般来说，这种堆积如山的软件产品的文档在哪里，例如Cp...事实上，是否有任何软件产品没有文档？很奇怪，你看不到这一点。

1...293031323334353637383940414243...48
新评论