巴解组织的间接费用 - 页 6

新评论
 
Maxim Kuznetsov:

但这并不奏效 :-)

我告诉你--试着去做，这是一个激烈的大量代码。Instantifiable类 "CFoo: public InterfaceCFoo "必须包含InterfaceCFoo *privateContext字段（建立1:1的关系），通过工厂创建和删除它，委托所有方法并在这里和那里翻译CFoo*引用this<->privateContext。这就是 "手工日落"，即用委托代替继承，而且是在现场。

通过工厂创建，并以通常的方式删除。你是否需要委托是由库的内容应该如何使用决定的：如果它提供的类可以自己完成工作，那么你就不需要委托什么--只需调用接口方法。

顺便说一下，在Android/Java 中，内核类也有类似的情况--由于缺乏多重继承，我们必须在对象中插入一个委托，并为其方法制定包装方法。这就是生活。

 
Maxim Kuznetsov:

我告诉你--试试吧，它是一个激烈的大量代码。Instantifiable类 "CFoo: public InterfaceCFoo "必须包含InterfaceCFoo *privateContext字段（建立1:1关系），通过工厂创建和删除它，委托所有方法，同时在这里和那里翻译CFoo*引用this<->privateContext。这就是 "手工日落"，即用委托代替继承，而且是在现场。

而语言呢，一个清醒的人不喝半升酒是无法理解他们的意思的。:)所有这些OOP的东西和所有这些中文知识都是为了--做一个简单的数据交换，这在程序层面上是很容易实现的...。
 
Andrei:
还有语言，一个清醒的人如果不喝半升酒，是无法理解我们在说什么的。:)而所有这些OOP的东西和所有这些中文知识都是为了--做一个简单的数据交换，这在程序层面上是很容易实现的...。

OOP本身并不能怪罪邪恶的OOP代码员的存在。一般来说，OOP没有错，你对OOP的看法是完全错误的。

 
Dmitry Fedoseev:

OOP本身并不能怪罪邪恶的OOP代码员的存在。一般来说，OOP没有错，你对OOP的看法是完全错误的。

你不知道它的历史。

屡次因直接破坏而被禁止。所以不要对他好战的无知做出反应。

 
Dmitry Fedoseev:

一般来说，OOP没有任何问题；你对OOP的看法完全错误。

我将从维基上给你一些关于OOP的著名的批评性引文，这些人由于某种原因没有被称为无知的人。

  • Alexander Stepanov 在他的一次采访中指出，OOP "在方法上是错误的"，"......OOP几乎和人工智能一样是个骗局......"[20]。
  • Niklaus Wirth 认为，OOP不过是结构化编程的一个微不足道的上层建筑，夸大它的重要性，除其他外，表现为在编程语言中加入越来越多时髦的 "面向对象 "的手段，损害了所开发软件的质量。
  • Patrick Killelia 在他的书 "Tuning the Web Server "中写道："......OOP给了你很多方法来减慢你的程序......"。
 
Andrei:

作为一种解放，我将引用维基上一些著名的关于OOP的批评性引文，这些人由于某种原因没有被称为无知的人。

  • Alexander Stepanov 在他的一次采访中指出，OOP "在方法上是错误的"，"......OOP几乎和人工智能一样是个骗局......"[20]。
  • Niklaus Wirth 认为，OOP不过是结构化编程的一个微不足道的上层建筑，夸大它的重要性，除其他外，表现为在编程语言中加入越来越多时髦的 "面向对象 "的手段，损害了所开发软件的质量。
  • Patrick Killelia 在他的书 "Tuning the Web Server "中写道："......OOP给了你很多方法来减慢你的程序......"。

而他们三个人：1950年出生的斯捷潘诺夫、1934年出生的维斯和同样古老的基列拉（他的书是1998年出版的）在2017年重复这一切会非常羞愧。

他们说的是很久以前的事，已经让人不好意思回忆了。C++编译器在优化方面至少是2个数量级的笨拙和原始。事实上，那里甚至没有一丝优化的痕迹。那时（九十年代初），我自己写了很多汇编程序，并有类似的想法："C/C++很慢"。

我不应该以摘取语录的形式进行链接。此外，你已经成功地在这个主题中显示了你的极端沉闷和咄咄逼人的无知。

 

Renat Fatkhullin:

更何况你已经在这个主题中设法显示了你的极端迟钝和咄咄逼人的无知。

让我们来总结一下。这是我对OOP的主要假设。"OOP只有在作为一个方便的文本包装器或在运行时初始化过程中尽量少用时才有意义...... "在帖子#10中。

而这里是一个独立专家的合理意见，有类似的意见和详细的代码级证明。

http://rainman-rocks.livejournal.com/122876.html

"从这一切中得出的最后结论是这样的。

面向对象的编程之所以有效，主要原因是它包含了提供模块化和声明性的手段。模块化和声明性才是提高开发效率的工具--即 "像银子一样的子弹"。它们应该是选择方法的重点。单纯的OOP不应该是目标"。

 
Andrei:

总结一下。这是我对OOP的基本假设。"OOP只有作为一个方便的文本包装器或在运行时初始化中最小限度地使用时才有意义...... "在帖子#10。

而这里是一个独立专家的合理意见，有类似的意见和详细的代码级证明。

http://rainman-rocks.livejournal.com/122876.html

"从这一切中得出的最后结论是这样的。

面向对象的编程之所以有效，主要原因是它包含了提供模块化和声明性的手段。模块化和声明性才是提高开发效率的工具--即 "像银子一样的子弹"。人们在选择方法时应该关注的正是这些。OOP本身不应该是目标"。

展示你亲自实施的项目，使你的意见至少在最小程度上被接受。你甚至不能理解引用的链接--它只是OOP的颂歌，包括输出。

所有的软件实际上90%以上都是根据OOP编写的（不要提关于驱动程序的废话）。事实上，如果没有OOP，就不可能编写和维护一个大型项目。当涉及到商业时，不接受任何关于 "只是一个包装纸 "的话。软件开发长期以来一直是一个完善的、经过时间考验的业务。

那些抱怨OOP而不理解的人并不清楚现代C++编译器的作用。在最终的代码中往往根本没有留下任何OOP的痕迹。当然，我指的是C++。

 
Renat Fatkhullin:

展示你个人实现的项目，这样你的意见至少可以得到最低限度的接受。你甚至不能理解所引用的链接--它只是对OOP的颂歌，包括结论。

让我再引用一句关于这篇文章的主要观点，这样就不会对它的内容产生怀疑。

"因此，OOP在寻求取代结构化程序设计的同时，最终又回到了几乎相同的东西，只不过是在花哨的包装下。有些问题出现了：这个演习到底有没有意义......"。

对不起，但我不理解这种逻辑和因果关系--为什么你需要任何实现的项目，以便一个人的意见被采取最小的考虑。通常在一个文明的讨论中，提交的意见本身的推理和合理性就足够了。

否则，我们就会得出一个荒谬的结论：如果一个人实施了一个项目，那么他后来的所有言论最初都必须被大家接受，尽管事实上它可能并不完全是顺理成章的，甚至与同样实施过项目的其他专业人士的意见相矛盾。

同样，夸耀某些东西是不太谦虚的，因为这对业力不利。

 

就是说，没有项目，因此没有经验。

同时，你不要忘记经验，试图拉出曾经有经验（就他们的时代而言）的人的最古老的说法。因为你没有自己的经验，所以你不明白，拿出来的话语早就不灵了。它们并没有发挥作用，只是那个时代特有的妄想。这些妄想已经让人难以回忆。

此外，你并没有真正理解所引用的链接中所写的内容的本质。你攫取词语并曲解它们，虽然它说 "OOP比拐杖好（而拐杖是在没有OOP的情况下试图模仿OOP），必须使用"。
1234567
新评论