应用太多的复杂性来应用最新的款式，框架和库来做一些简略的事件是很容易的。吻很艰巨。
如果您听其余语言社区（例如 Python 或 Ruby），则 Java 开发人员仿佛偏向于适度设计。
兴许他们只是嫉妒咱们的高级平台（眨眼），兴许有一些十分渺小的起因让他们置信。我置信是这样。我通过进行代码审查意识到了这一点，这很乏味，只管我可能会在编写代码时适度设计本人。然而我正在致力。
当然，您是一个“简略”的开发人员，只有架构师能力设计，所以只有他们能力承当适度工程的责任，不是吗？恐怕并非如此：开发人员始终都在这样做。在本文中，我将重点介绍我在评论中评论过很多的一种症状，但能够将其扩大到其余许多症状。
在我职业生涯的晚期，我曾被教诲要设计我的班级层次结构，使其尽可能地可扩大。它转换为由具体类实现的父接口。有时，它们之间甚至可能有一个抽象类。它看起来像上面的图：
看起来很棒，它形成了可扩大的层次结构，并且实现了接口范式的编程。
例如，Spring 框架在其整个软件包中都大量应用此设计。一个很好的例子是 ViewResolver 接口，它具备丰盛的子级层次结构和许多不同的实现类。例如 InternalResourceViewResolver 和 VelocityLayoutViewResolver 等。在框架的不同局部，还有许多其余示例（bean 注册核心，上下文等）。
然而，请留神无关 Spring 的一些重要事实：
在结构化的层次结构中组织了许多不同的子类。
这是一个 框架，它的意思是能够扩大，但不能批改。
回到咱们以后的我的项目 - 假如是一个惯例的 Web 应用程序。找到定义的接口之一。从这一点登程，很容易找到其子实现。在大多数状况下，只有一个，并且以 Default 为前缀（或者以 Impl 作为后缀）。同样，在大多数状况下，该接口位于 xyz 包中，而实现位于 xyzimpl 中。人们可能会对这种齐全不足想象力的货色感到好奇。嗯，很难为实现提供一个相干的名称，因为它与接口之间没有语义上的区别，即前者没有专门化后者。惟一可能的论断是该接口不是必须的！
一些架构师可能会辩论说，即便当初没有用了，形象也可能在当前有用。然而，仅因为未来可能会变得有用而增加不必要的代码只会升高代码库的信噪比 - 毫无理由地障碍了可读性。此外，须要创立，测试和保护这些额定的代码，因而减少了老本和节约。这与“足够”实现目标的麻利办法相同。最初，如果（且仅当）须要呈现时，只需更改应用程序的代码即可很容易地引入父接口。毫无疑问，得益于该名称的任何 IDE 的重构性能。
如果有人成心设计上述办法认为假如的将来做筹备，那么我将上述办法视为适度工程，而如果仅仅因为它始终都是这样，就将其视为“货运崇拜”。
无用的接口只是适度工程的一个简略示例。还有更多。我很快乐浏览您发现的（或练习过的）那些。
参考：《2020 最新 Java 根底精讲视频教程和学习路线！》
原文链接：https://blog.csdn.net/weixin_46699878/article/details/113428934