多少抽象太多了? [英] How much abstraction is too much?
问题描述
在一个面向对象的程序中:多少抽象太多了?多少钱合适?
In an object-oriented program: How much abstraction is too much? How much is just right?
我一直都是个小人物.我了解高级封装和抽象背后的概念，但总是本能地认为添加太多内容只会使程序感到困惑.
I have always been a nuts and bolts kind of guy. I understood the concept behind high levels of encapsulation and abstraction, but always felt instinctively that adding too much would just confuse the program.
我一直试图拍摄一些抽象的东西，而没有留下任何空白的类或层.如有疑问，我会尝试在现有层中添加一些内容，而不是在层次结构中添加新层.
I always tried to shoot for an amount of abstraction that left no empty classes or layers. And where in doubt, instead of adding a new layer to the hierarchy, I would try and fit something into the existing layers.
但是，最近我遇到了更多高度抽象的系统.那些可能需要在层次结构中稍后进行表示的事物的系统先入为主.这导致了很多空层，一开始似乎是不好的设计.但是，经过深思熟虑，我逐渐意识到，保留那些空的层将使您有更多的空间可以在将来进行重构，而无需进行过多的重构.这样一来，您就无需在调整旧版文件上做几乎所有的工作即可在旧版文件上添加新功能的能力更大.
However, recently I've been encountering more highly abstracted systems. Systems where everything that could require a representation later in the hierarchy gets one up front. This leads to a lot of empty layers, which at first seems like bad design. However, on second thought I've come to realize that leaving those empty layers gives you more places to hook into in the future without much refactoring. It leaves you greater ability to add new functionality on top of the old without doing nearly as much work to adjust the old.
这种情况的两个风险似乎是您可能弄错了您需要的图层.在这种情况下，仍然需要进行大量的重构以扩展代码，并且仍然会有大量的未使用层.但是，取决于您花费多少时间来进行初始抽象，将其搞砸的机会以及如果正确就可以在以后节省的时间-仍然值得尝试.
The two risks of this seem to be that you could get the layers you need wrong. In this case one would wind up still needing to do substantial refactoring to extend the code and would still have a ton of never used layers. But depending on how much time you spend coming up with the initial abstractions, the chance of screwing it up, and the time that could be saved later if you get it right - it may still be worth it to try.
我能想到的另一个风险是过度执行该风险并且永远不需要所有额外层的风险.但这真的很糟糕吗?额外的类层真的昂贵吗，如果不使用它们，会造成很大的损失吗?这里最大的开销和损失将是时间，这些时间是与各层一起预先损失的.但是当人们可以使用抽象代码而不是更多的低级代码时，大部分时间仍可以节省下来.
The other risk I can think of is the risk of over doing it and never needing all the extra layers. But is that really so bad? Are extra class layers really so expensive that it is much of a loss if they are never used? The biggest expense and loss here would be time that is lost up front coming up with the layers. But much of that time still might be saved later when one can work with the abstracted code rather than more low-level code.
那么什么时候太多呢?在什么时候空层和多余的可能需要"抽象变得过大?太少太少了?最甜蜜的地方在哪里?
您在职业生涯中是否找到了可靠的经验法则来帮助您判断所需的抽象量?
Are there any dependable rules of thumb you've found in the course of your career that help you judge the amount of abstraction needed?
推荐答案
那么什么时候太多呢?在什么时候 做空的层和额外的力量 需要"抽象变得矫kill过正? 太少太少了?在哪里 甜蜜点?
So when is it too much? At what point do the empty layers and extra "might need" abstractions become overkill? How little is too little? Where's the sweet spot?
我不认为这些问题有明确的答案.需要经验来发展对太多"和太少"的感觉.也许某些度量或质量控制工具的使用可能会有所帮助，但是很难一概而论.这主要取决于每种情况.
I don't think there is a definitive answer to these questions. Experience is needed to develop a feeling of what is "too much" and "too little". Maybe the usage of some metric or quality control tools can help, but it's hard to generalize. It mostly depends on each case.
以下一些链接可能会启发您寻求答案:
Here are a few links that might inspire you in the quest of answers:
- You ain't gonna need it
- The use/reuse paradox
- Project triangle: good, fast, cheap
- All problems in computer science can be solved by another level of indirection (David Wheeler)
开发的全部目的是在任何软件工程工作中都存在的各种紧张关系之间找到适当的平衡.
Development is all about finding the right balance between the various tensions that are present in any software engineering effort.
这篇关于多少抽象太多了?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
