GRASP: application of the creator pattern
Craig Larman (Using UML and patterns , p. 352) proposes the following design problem:
Whose responsibility is it to create a payment instance?
By default GRASP Creator, the candidates are the Register class and the sell class.
In the case of the sale class, it justifies that it is a candidate by being "reasonable to think that it uses payment in a close manner".
I couldn't understand from where he takes it. I thought of two possibilities:
After a full sale comes a payment.
After a payment will be returned change, and the calculation of this change comes from the difference between the total of the sale and the amount provided in the payment.
Is there any other relationship between Sale and payment that I can't see?
1 answers
Concept represented by an object
An object-oriented project will have classes and the corresponding instances need to be created. GRASP contributes the creator pattern for the purpose of guiding who should create an instance of a given class. In time, it is a heuristic, not a rule.
One of the propagated benefits of object orientation is to more faithfully reflect the domain in question. That said, note his statement, " after a sale complete comes a payment". If in your domain in question this statement is true, then it makes no sense for the sale class to create a payment instance, as you suggest. And there is no problem here.
In other scenarios, a payment does not occur after the sale, but is part of a sale. The sale, the concept, the notion of sale is the transaction effected between customer and supplier, in which one or more products is marketed, for which there is an order, an invoice, one or more budgets, a payment, an installment,... All this can be part of the sale. Anyway, the question here is how it is defined sale in the domain in question. Additionally, note that does not have a single correct definition. In fact, in the same institution, the same concept can be represented from several different perspectives, depending on the use that is made of it in the context in question. Currently, we can say that each of these contexts is a bounded context (Domain-Driven Design) and that will be implemented by a micro-service.