(sample is taken from the Mockito page, actually mixing two examples). I assume that you are familiar with mocking and mockito. Mockito is a mocking framework, which we usually use in unit tests. Let me look at something more complex that breaks SRP. Singletons are simple and discussed more than enough in blogs. Public static Singleton getInstance() īut there is not much use of such a beast. Private static final Singleton instance = new Singleton() You can easily create a singleton that does not violate SRP keeping the first responsibility and drop the second one Do something that is the original responsibility of the class.Manage the creation of the instance of the class.The anti pattern-ness of singleton generally comes from the fact that it breaks the SRP.
Many thinks that singleton actually is an antipattern and I also tend to believe that this is better to use some container to manage the lifecycle of the objects than hard coding singletons or other home made factories. This pattern restricts the creation of an object so that there is a single instance of a certain class. The oldest and simplest pattern that breaks SRP is the singleton pattern.
This is also true for other principles, but this time I would like to talk about SRP. But from time to time you may see solutions, patterns that break the SRP and are kind of OK.
Single responsibility principle java code#
It exists to help the code maintainability and readability. Single Responsibility Principle (SRP) is not absolute.
0 kommentar(er)
