花了一些时间在Haskell和其他功能语言中玩弄，我逐渐体会到从广义上描述问题所带来的设计的简单性。尽管模板编程的许多方面可能都不是那么简单，但是某些用法很常见，以至于我不认为它们妨碍了清晰度(尤其是函数模板)。我发现模板通常可以简化当前设计，同时自动添加一些将来的抵抗力。为什么要将它们的功能委托(delegate)给库作者？
另一方面，有些人似乎避免使用鼠疫之类的模板。我在十年前就了解了这一点，当时泛型类型的概念对于大多数编程社区来说都是陌生的。但是现在所有流行的静态类型的OO语言都支持一种形式或另一种形式的泛型。熟悉程度的提高似乎需要对保守态度进行调整。
最近向我表达了一种这样的保守态度:
老实说，我很惊讶地看到这句话如此不屑一顾，好像它本来就很明显。就我个人而言，我发现这远非不言而喻，对于像Haskell这样的语言，除非您另外指定，否则一切都是通用的。话虽如此，我想我理解这种观点的来历。
在我的内心深处，我确实有类似的规则在四处轰动。既然它处于最前沿，我意识到我总是根据整体架构来解释它。例如，如果您有一个类(class)，那么您不想在一天中使用很多功能来加载它。如果只需要一个具体的版本，则不要打扰创建接口(interface)(尽管可模拟性可能与此版本相反)。像这样的东西...
但是，我没有做的是将此原则应用于微观层面。如果我有一个小的实用函数，没有理由要依赖任何特定类型，那么我将创建一个模板。
那么，您如何看待呢？您认为什么过于笼统？根据上下文，此规则是否具有不同的适用性？您甚至同意这是一条规则吗？
最佳答案
过度概括使我发疯。我不害怕模板(不远处)，而且我喜欢常规解决方案。但是我也喜欢解决客户要付钱的问题。如果这是一个为期一周的项目，为什么我现在要资助一个月的盛会呢？这种盛会不仅会通过 future 可能发生的明显变化(例如新的税收)，而且可能还会通过发现新月或火星上的生命而继续起作用？
将此内容带回到模板中，客户端会要求您提供一些功能，这些功能涉及您编写带有字符串和数字的函数。您给我提供了一个模板化的解决方案，该解决方案可以采用两种类型，并针对我的具体情况做正确的事情，而在其余情况下可能做对或不做做(由于没有要求)，我将不胜感激。我会打勾的是，除了支付给您的费用之外，如果将来发生更一般的情况，我还必须支付费用进行测试，记录的费用以及在您的约束范围内工作的费用。
当然，并非所有的概括都是过度概括。一切都应该尽可能简单，但不要简单。视需要而定，但不再更一般。经过我们力所能及的测试，但再也没有测试了。等等，“预测可能发生的变化并将其封装起来”。所有这些规则都很简单，但并不容易。因此，智慧对开发人员和管理人员至关重要。