The fourth refactoring is the lazy class.
Lazy class. A state in which the class is lazy with little behavior. (I don't understand the meaning of existence)
There is no need. Be redundant.
A common structure is to create the following service class for the time being and throw the process there.
package study.lazyclass
class PaymentController {
def payment(amount: Int) = {
val service = new Service
service.pay(amount)
}
}
class PaymentService {
def pay(amount: Int): Unit = {
paymentRepository.save(amount)
}
}
Only the pay method is defined in the PaymentService class. The Service class only has the behavior of a pay method.
The solution itself is very simple.
Function inlining You can make it when you need it. The only time to create a class is when you need a class that organizes functions, such as when it is called from two or more places.
class PaymentController {
def payment(amount: Int) = {
paymentRepository.save(amount)
}
}
I am changing to call paymentRepository directly from PaymentController.
This is in line with the well-known YAGNI law.
[https://ja.wikipedia.org/wiki/YAGNI:embed:cite]
Here is the important point of view of this code smell.
lazy class Reda factoring itself is very easy, but ** whether or not to actually do refactoring depends on the development method. ** **
If you are thinking of an architecture that adapts from the beginning, such as thinking about application configuration with a layered architecture, there is no need to refactor as described above.
Even if you have only one function, you need to separate and define the layers properly.
For example, if you are using a layered architecture, you have to design the dependencies to be one-way from top to bottom as shown in the figure below. It is not possible to call repository (infrastructure layer) from controller (presentation layer) like refactoring code.
Therefore, it is necessary to proceed with development while allowing some code smell.
However, ** If you think about the architecture from the beginning, you have to follow the rules of that architecture, which makes writing code cramped, so basically you should think about the architecture from the beginning of development. Some developers say they don't. ** **
Therefore, the team should consider what kind of development method to take and decide the development rules.
The lazy class has been refactored.
Thank you until the end.