CODEWITHSUNDEEP
classarchitecturesingle-responsibility-principle
jasperdunn
jasperdunn

Reputation: 111

Deciding on class responsibility

I know this is an opinionated question. However it comes up often at work. When creating methods it's often a struggle to know which class should be responsible.

e.g.

bool result = ProductService.CategoryHasSoldOutOfProducts(int categoryId)

vs

bool result = CategoryService.CategoryHasSoldOutOfProducts(int categoryId)

In my opinion, the CategoryService should be responsible, as the method is taking a categoryId and is specific to the Category.

Others at my work say the ProductService should be responsible as the method is dealing with if Products have sold out.

Just trying to develop a better understanding of service architecture and good process. I'm interested in other peoples explanations for why they would choose one over the other.

Thanks

Upvotes: 1

Views: 96

Answers (2)

Shryne
Shryne

Reputation: 121

Since you're asking for opinions, here is mine: (Disclaimer: That's probably something you cannot easily implement in the business world)

As you are using the term "class", I assume you want to have something object-oriented. The problem is, a service is nothing a valid object could be created from. Instead, it's just a namespace for functions.

Additionally it's very general. It's like calling a class "Manager". You can put possibly everything inside of it and this class has the potential to grow to have hundreds of functions.

My advice: Create small entities. Small enough to be created without the use of any setters, just by calling the constructor. If you notice your object needs more functionalities, create a decorator that is a little bit smarter and can do the work for you.

I would need a few more details about your environment to be more precise, but I guess in your case, you would have something like a Category class that contains products and knows when it's sold out. Just imagine you have a team of persons and everyone knows something. Ask the right guys to do the stuff and stay away from managers or services.

Upvotes: 1

Rann Lifshitz
Rann Lifshitz

Reputation: 4090

Disclaimer - this is a purely IMHO answer. I am answering this in the spirit of having a design brainstorm.

Based on the OP, it seems the relationship between Category and Product is an optional one to many : Category (0..1) <--------> (*) Product.

Implementation wise, this means that the Category entity probably has a Container of Products, and the Product entity has a reference to a Category which may be NULL.

In this case, I agree with the decision to place CategoryHasSoldOutOfProducts under the responsibility of the Category entity. The method name clearly implies that the Category entity should be responsible for informing its API user on the status of its products.

There is another option, however: An association class/entity. The motivation behind this entity is to describe the relationship between two other entities.

In this case, you can have a functional association entity which we will call ProductContainment for the sake of this example.

ProductContainment will have no internal state, and will hold functions which are provided with Category and/or Product entities as parameters. It is then the responsibility of the association entity to provide the implementation of functions which relate to how Category and Product relate to one another.

If you end up using ProductContainment - then CategoryHasSoldOutOfProducts should be one of its functions.

Upvotes: 1

Related Questions