GRASP: Application of the Creator Pattern

Asked

Viewed 73 times

2

Craig Larman (Using UML and Standards, p. 352) proposes the following design problem:

Who is responsible for creating a Payment instance?

By the GRASP Creator standard, candidates are the Registrar class and the Sale class.

In the case of the Sale class, he justifies that she is a candidate for being "reasonable to think that she uses Payment in a near".

I couldn’t figure out where he gets it from. I thought of two possibilities:

  1. After a Full Sale comes a Payment.

  2. After a Payment will be returned change, and the calculation of that 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?

oop software-project

  • Call it here :D Have you read all or have you only seen this passage? Does it not justify? Throw it away :D

  • I read everything. Will I have to play? : I thought I was missing something obvious, but if more people didn’t understand too, at least I don’t stay the only one. :)

  • Publication date?

  • The book is from October 2004.

  • To tell the truth anything that has UML in the name I discard, everything is fundamentally wrong, anyone who dedicates himself to writing it does not have much credibility with me. It may be that today the person has changed his mind, but the author at that time believed in something that adds nothing very useful, brings new problems, and today there are those who already see it.

  • He seems like a theoretical guy who’s never done a real system, but he just seems like, I don’t know, it might just be someone who can’t give good definitions. If it’s about selling, there should be a receipt, not a payment. Usually the receipt has to do with the financial doesn’t go through the sale, but I don’t know the context, he might be right. It is what I say, there is no book that teaches modeling right, nor the abstract base, imagine when you need to do something concrete. I wanted someone to give a coherent explanation, but I don’t think even the author can. Is it possible to contact him? Put on Soen and call him

  • It’s a PDV project for selling products in a supermarket or something, you’re referring to the buyer paying cash for the purchase. I don’t think the author is contactable, I have at least tried to talk to him and failed to.

  • From the point of view of the company that made the sale, it receives, because if you look at the customer’s point of view, it is already wrong because the system is not for him, but if he does this, the payment must be made in a purchase. I still think it’s something poorly structured, and there’s probably no direct connection between things. Maybe there were so many people complaining about the book that he disappeared :)

  • Either that, or he just doesn’t bother to answer emails with random questions. : P but gives a credit for the book, it is well recommended by Martin Fowler and Alistair Cockburn, if their recommendation is worth anything. : P

  • Fowler has his ups and downs, a lot of what he says is marketing, you never know when that’s all. And I don’t know if he hasn’t changed his mind over time, he’s the one who’s preached things that he doesn’t preach anymore, but he stays quiet. I don’t know what he did, I don’t know if it looks good. The other you can read my link in chat (on Linkedin) what I think about Agile, so I won’t even comment.

  • There’s Vlissides too. : ) the case is that if you exclude the approaches with UML you don’t have any, all the ones I found use (after-97 at least).

  • @Maniero I think I had not spoken before, but the Sale is probably not a Purchase because the use case is from the cashier’s point of view (clerk).

Show 7 more comments

1 answer

1


Concept represented by an object

An object-oriented project will have classes and the corresponding instances need to be created. GRASP contributes to 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 benefits of object orientation is to reflect more faithfully the domain in question. That being said, note his statement, "After a full sale 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’s 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 effective transaction between customer and supplier, in which is marketed one or more products, for which there is an order, a invoice, one or more budgets, a payment, a installment, ... All this can be part of the sale. Anyway, the question here is how is sale defined in the domain in question. Additionally, please note that there is not a single correct definition. In fact, in the same institution, the same concept can be represented from several different perspectives, according to the use 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.

  • Thank you for the reply, very well noted that Payment is part of Sale and not just "come after", I will only exempt myself from evaluating the quote to microservice which is a topic that I do not understand.

  • Note that it is a "conceptual" issue. It may be that in a given scenario, the concept of "payment" is not part of "sale", and this can happen in the same system, in this case it should be in another "micro-service", to illustrate a proposal of software architecture widely commented at the time. The design should be close to the domain, if the domain says it is part, then it does, if it says otherwise, then it does not.

Browser other questions tagged oop software-project

You are not signed in. Login or sign up in order to post.