3

I'm reading the Clean Code book and a chapter says that if a class has more than 3 dependencies is a code smell of that class isn't doing one thing. Or what is the same, it isn't following SRP. I'm thinking in certain scenarios in which I am unable to reset the number of dependencies to stick to that number.

Let's say we have an app that connects to a public API REST what offers varied information about a lot entities in our domain. In our app we detect an use case repeated in many places where we request to the API the info about an entity with other dependent entities that it has.

The API REST doesn't offer the data in the format we want because the calls when can make are to get data from a single table on the web database, not offers the data agrouped with other tables as we want. So our use case have to make different Api Call's for to get all different data about the entities we need and then merge in the model we will use in the app.

To connect with the external subsystem we will hide implementation in a single Service class however this class has grown too much resulting a class with a lot methods to get data about all entities of the api rest. So we split this huge class into differents following the Repository pattern. Each class for each possible operations with an entity on the API.

Then, to hide all this concrete and common interaction with the service layer we will use a Facade class to coordinating all this calls. The problem I'm figuring it will have, is that it will have a lot dependencies in her constructor. Will have classes for each repository class and mapper classes to adapt the web data into app data.

The solution in these cases is merge all related dependencies in one so you reduce the number. One example is this: Refactoring to Aggregate Services. http://blog.ploeh.dk/2010/02/02/RefactoringtoAggregateServices/

But you merge when you see a clear relationship. What happend if in your class you can't see that? All classes are granulated but all of them are necesary to achieve the goal but can't not be merged in an aggregate service.

So my question is, the "rule" that more than three dependencies violates SRP is always applicable? Returning to our example, our facade needs to access many repository classes and mapper classes. The mapper classes can be hide on a agreggated service, maybe, but repository classes are fine like are. We could introduce a service locator to store them but it is a very bad practice.

Improve this question
1
  • 1
    A code smell is a rule of thumb; something that you generally want to look into. It is not something that is automatically and always evil and must be reworked. And three is not a magic number. Just use common sense. Sometimes this can be justified, sometimes not (everyone’s mileage varies).
    – Mawg says reinstate Monica
    Mar 27, 2015 at 16:14

1 Answer 1

Reset to default
2

Yes. There is always a way to do this as you can always keep piling abstractions on top of each other. For example, you can combine a mapper and a repository into a service class. Or you can split a single class with different calls to the REST API into a separate class per call.

The real question is not if you can but if you should. Does your application benefit from this hard rule and the added complexity that might come with it?

Improve this answer
3
  • 1
    Note that a code smell is not a hard rule. It is a reason to investigate, not a reason to act. After all, the smell might be a fine cheese, not necessarily rotten food.
    – Jörg W Mittag
    Mar 27, 2015 at 11:19
  • 1
    Thus the "smell" analogy jumps the shark.
    – kojiro
    Mar 27, 2015 at 11:47
  • @JDT Totally agree. The obvious solution, as you say, is to combine the repository class with the mapper class in a service class. For example, "MoviesRepository" and "MoviesMapper" in "MoviesRESTService" for example. But if the use case needs to access to different "xxxEntityService" to combine a lot data to present in a single model, I don't see any possible combination. Maybe you can create others groups but in some points I think can be difficult to put a name to the class.
    – korima
    Mar 27, 2015 at 11:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.