模式是从开发人员那里汲取的智慧和教训，这些开发人员多年来一直在为大多数常见问题设计解决方案。不使用它们会很天真，尤其是当我们面对类似情况时。但是，在使用它们之前，我们必须了解它们的实现宗旨。在我们的日常编程中，有许多此类模式可利用。本文选择了其中最常见的一些，并展示了如何以简单的方式实现。
总览
马丁·福勒（Martin Fowler）说：“...模式的关键部分在于它们扎根于实践。你可以通过观察人们的行为，观察有效的事情来找到模式。” 找到一个模式并不总是那么容易，但是一旦找到，它们就非常有价值。设计模式应被视为良好的建议，这是经验的支持，而不是一种天意。根据现有的模式可以解决类似的问题，但是同样可能存在例外。
说了这么多，我们在这里讨论的模式如下：Singleton，Utility，Factory和DependencyInjection。请注意，我们之所以选择这些并不是因为它们是最常见的四个，而是因为它们只是最常见的四个。让我们深入研究。为了实现，我们将使用Java作为语言。
单例模式
该单件模式，从开发者的主要需求演变为创建一个类，保证只有一个类的单个实例可以在任何给定时间点创建。人们可能在某种程度上不同意该假设不完全符合线程安全性原则。但是，经验表明，在某些情况下我们确实需要它们。从实现的角度来看，这是最简单的模式。这种设计的原始版本可能如下所示：
但是，上述简化代码存在问题。多个线程不能同时调用它，因为它将创建多个实例。克服此限制的一种方法是如下修改代码。请注意，这是一个非延迟实现。
如果我们要确保不浪费资源并仅在需要时才懒惰地创建实例，则可以通过显式同步来实现。这样可确保在多线程环境中的低并发性。
我们必须了解，在项目中具有许多单例模式是绝对不可以的。这意味着类设计不正确，需要重新考虑。另外，单例模式使代码难以测试。最好改用依赖注入，因为我们可能认为我们需要一个Singleton模式。
效用模式
该实用程序或辅助模式是非常有用的创建一个非实例化类。因为Java通过使用final关键字使它变得容易，所以在这里我们将集中在不使用final的情况下实现。实用程序或帮助程序类通常有助于将各种无关的方法放在一个地方。但是，这不是一个好主意，如果我们要遵循面向对象的重用原理，代码的简洁性等，则最好避免，但是似乎我们无法完全避免它们。因此，实用程序模式确实具有一定的实用性！
现在，如果要在代码中实现此模式，则在类中声明的方法都应该是static。就像你可能已经猜到的，如果我们不使用final关键字，那么确保非示例性的唯一方法是将构造函数声明为私有。Java具有final关键字的优势，但是其他面向对象的语言（例如C ++）可能没有该选项。因此，将构造函数声明为私有是实现此模式的方法。
工厂方法模式
该工厂方法模式是一种极为有用的图案，并已在Java API设计中广泛使用，例如，从工厂方法抽象工厂。这个想法是使用一个接口来创建一个对象，但是最终一个子类将决定实例化哪个类。因此，目标是通过允许系统确定要在运行时实例化的类来推迟创建对象。工厂方法模式的一个简单实现是返回特定类的对象的静态方法。
这是一个非常幼稚的实现。我们可以通过使用接口或抽象类，换句话说，使用抽象工厂，将代码修改为另一个变体。这种模式利用了代码的可读性。
减少样板代码
利用关注点分离
扩展灵活
易于测试
不过要谨慎一些；绝对不能过度使用依赖项注入，因为它可能导致不必要的维护问题。此外，由于有时会隐藏服务类，因此仅在运行时才能捕获在编译时会出现的错误。这在调试时会带来困难。
结论
这些只是日常编程中使用的快速流行的四种模式。在这里，我们试图给出仅四个的快速概述。还有很多其他的 依赖项注入模式稍微复杂一些，但是到目前为止，这是解决关注点分离问题的最佳方法。完全可以在编程时不使用任何模式，但是问题是，如果我们找到匹配项，为什么不使用一个模式。有经验的程序员总是尝试在模式列表中找到解决方案，并在可能的情况下使用它们。
