在休息室谈论巴解组织的问题 - 页 19

新评论
 

沃尔钦斯基，你也可以给自己写一个名为 "你需要得到"的合唱题目。

 
Andrei:
维罗格

好吧，这有点抓狂了，不是吗？)它是用来设计电子电路的。

 
o_o:

沃尔昌斯基，并为自己写下另一个喧嚣的话题 "你需要得到 吗？"


我假设你有负面的感觉，这样做对吗？这是为什么呢？

 
Комбинатор:

这有什么区别呢？

你需要论证你的主张（OOP很烂）--去谷歌，输入 "OOP "和一些负面的品质，取一篇文章，不看就扔到论坛上。

真实或不真实--这并不重要。我是或不是都无所谓。如果有像你这样细心的人愿意费心阅读和检查，我们可以用同样的方式再扔一篇文章。

我是一个OOP的初学者，所以我很可能承认我还没有意识到OOP的一些严重缺点。我把这篇文章作为最重要的一篇，因为我认为它看起来是一个严肃的编程资源。也许不是这样，但我也不是一个程序员。

因此，你也许应该进行一项社会学（或心理学）研究，为什么社会的一部分（个人）会对某些东西产生几乎是侵略性的、持续的厌恶。
 
George Merts:

嗯，我也不被小鸡喜欢......还有更多...这是很常见的事情，阿列克谢，他们都是动物，不是每个人都能训练他们，所以你会有很多羡慕的人。

但你最好告诉我--你的课程在哪里？我也要看一下...


你不需要它，我亲自给你送去了。

 
fxsaber:

OOP的一个严重的缺点是，复杂的东西很难设计，即很难做出一个不需要拐杖就能很好地工作和配合的架构，所以重构非常非常普遍。你的设计经验越少，你就越能把它变成地狱。问题是，在OOP中，正常设计的对象模型的结构往往与真实的对象（如我们想象的那样）没有什么共同之处。

然后，它取决于某些语言对某些范式的支持，这样我们就可以谈论 "好/坏"、"适用/不适用"

例如，上面提到的大猩猩和香蕉并不是一个OOP问题，它是一个无意识地使用包管理器而没有依赖性跟踪的问题。特别是在最近的网络上

 
fxsaber:

这篇文章 在说谎!

当我读到这个声明时，我变得非常怀疑。我赶紧把它翻过来，检查我的脑子是不是乱了。

我强调了文章作者建议修改的那几句。替换它们并不影响结果。我没有阅读文章的其余部分。最有可能的是，在评论中指出了作者的这种无稽之谈。


这篇文章没有说谎。那里有虚拟函数，所以都是按照作者所说的方式工作。

但我希望你不要把它当作反对OOP的严肃论据。

基类的变化可以大到你想要的程度，而期望它们不影响派生类的工作则是愚蠢的。

 
Koldun Zloy:

这篇文章没有说谎。那里有虚拟函数，所以一切都按作者写的方式工作。

但我希望你不要认为这是一个反对OOP的严肃论点。

对基类的修改可以随心所欲，指望它们不影响派生类的工作是很愚蠢的。

如果是虚拟的，那就说得通了，作者对虚拟功能的 问题和挑战根本无能为力。

此外，如果他必须获得独立，他应该做的是

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array:: add(elements[i]);
}
但我发现这个例子对初学者来说是个好例子。你需要了解你在做什么。
 
Комбинатор:

OOP的一个严重的缺点是，复杂的东西很难设计，即很难做出一个不需要拐杖就能很好地工作和配合的架构，所以重构非常非常普遍。你的设计经验越少，你就越能把它变成地狱。问题是，在OOP中，正常设计的对象模型的结构往往与真实的对象（如我们想象的那样）没有什么共同之处。

然后，它取决于某些语言对某些范式的支持，这样我们就可以谈论 "好/坏"、"适用/不适用"

例如，上面提到的大猩猩和香蕉并不是一个OOP问题，它是一个无意识地使用包管理器而没有依赖性跟踪的问题。特别是在如今的网络上。

是的，我遇到过一些架构选择不当的情况。有时，从头开始重写比编辑更容易。

在程序性编码中，你几乎总是可以在编写代码的同时构成一个程序的架构。因为自由和灵活性是完全的，但赌注是巨大的。

另一方面，在OOP中，在写第一行代码之前，最好先把整个架构写在黑板上。当你准备好了，写代码就非常容易了。而且，如果架构是成功的（这里只有经验和个人技能有帮助），完善/扩展也同样容易，即使你已经忘记了这个项目 的一切。

 
Alexey Volchanskiy:

嗯，你的握力还真不错）。它是用来设计电子电路的。

不仅如此。
1...121314151617181920212223
新评论