我的方法。核心是引擎。 - 页 137

新评论
 
Nikolai Semko:
彼得，你真的误解了一些关于OOP的应用。
对不起，但这有精神分裂症的味道。

尼古拉，你是在建立IERARCHY还是在创建绘图机制？

如果你建立了IERARCHY（不关心画图），那么就很清楚为什么你到处需要OOP。

如果你创建的绘图机制 是在一个类的基础上工作，那么你就不需要类本身。


类，--来自分类一词。分类是按属性划分的。类是分类的衍生物。如果有一个类，那么就没有分类。

因此，在这种情况下，阶级是抽象的废话。这是不可能的。

 
这不是单单是类的问题，而是实现的问题。
 
Реter Konow:

...

人们的印象是，OOP本身比它所要服务的机制更早。也就是说，该机制必须努力追求完整性，因此其区块的数量要最小。但OOP迫使这些块因任何原因而相乘。因此，机制的结构被打破，它们不能很好地工作。而他们的发展甚至更糟。

...

好吧，也许你应该至少研究一下OOP，而不是幻想它？你甚至不幻想，你是神志不清。

 
Реter Konow:

尼古拉，你有没有想过，你对OOP的热爱，除了抽象的原因，几乎没有任何理由。

说，如果你用这种OOP创建巨大的机制，就会明白为什么你这么需要它。你会特别证明你为什么需要OOP。但是，你创造了相对较小的机制。那里没有足够的代码来得出关于这种或那种方法的缺点和优点的结论。但你还是一直在谈论OOP。而OOP只是一个工具，本身没有任何意义。也就是说，如果没有机制可言，OOP就没有必要。但是，如果有一个机制，它应该足够严肃，以至于在创建它时需要OOP。

大多数为OOP站台的人并没有做出什么严肃的事情。他们只做小事。然而，他们对OOP的信念是不可动摇的。其他那些做得更严肃的机制的人就更不可能喊出OOP的伟大了。有些人甚至说出了批评的话（有几次）。

因此，你的论点需要有实践的支持，而不仅仅是理论。例如，我可以和Anatoly争论OOP在GUI开发中的好处，因为我们可以比较解决方案和它们在实践中的细微差别。但是，对于你，我无法部署我的论点，因为你不会理解它。你会的，但你不会理解它（无意冒犯）。相反，阿纳托利却能很好地理解它。创建全球机制的经验差异是造成误解的主要原因。

作为一个实践者，我要告诉你：方法必须是这样的，它将最大限度地发挥特定程序员的大脑潜力。我已经为自己找到了这样一种方法。

对OOP的幻想越来越疯狂......

工作的严肃性是由结果决定的，而不是由花费的年限决定的。

 
Реter Konow:

唉，这不是胡说八道。

在画布上作画不需要类的包装。有一个功能清单就足够了。你不需要任何方法的访问 权限就可以画画。你也知道。但你否认了这个事实。你在否认明显的事实。

哦！是的，要吃香蕉，你必须剥掉皮。但如果一头牛有角，那么每个有角的人都是牛。

 
Реter Konow:

嗯，这里没有多少这样的人。我可能是他们中的一员。虽然，这不是为了教你。只是想听到一个合理的答案。如果你只使用一个类，为什么在绘图时，你要通过对象来引用类的功能？

因为画布上的绘画函数只指画布上的绘画，而不是其他，所以没有理由把它们放在一个单独的仓里，这就是为什么它们被收集在一个类里。但无论如何你都不会明白。

 
Реter Konow:

尼古拉，你是在建立IERARCHY还是在创建绘图机制？

如果你建立了IERARCHY（不关心画图），那么就很清楚为什么你到处需要OOP。

如果你创建的绘图机制 是在一个类的基础上工作，那么你就不需要类本身。


类，--来自分类一词。分类是按属性划分的。类是分类的衍生物。如果有一个类，那么就没有分类。

因此，在这种情况下，阶级是抽象的废话。这是不可能的。

等级制度与此有什么关系？OOP广泛使用了继承性......又是一堆猖狂的幻想...

 

......还有蛋糕上的那颗樱桃。

蛋糕上面的樱桃

 
 


我有一个类似的项目，用的是另一个相当昂贵的软件，我也用变通的方法实现了这个想法（以便不买额外的模块）。

我曾在另一个相当昂贵的特殊软件上做过一个类似的项目，也是通过变通方法实现的（以便不购买额外的模块），它是有效的，但在一些客户那里却陷入了僵局，浪费了时间。

但这是一个完全不同的领域，它很容易找到客户

1...130131132133134135136137138139140141142143144...184
新评论