I am working with Sping Tools Suite and validating with SonarQube, I am a student and I am doing an internship for a company.
When I created the Class "Service" SonaQube showed me the following warning: Split this class into smaller and more specialized ones to reduce its dependencies on other classes from 25 to the maximum authorized 20 or less.
I solved this "error" by creating an Extend Class where I placed some local Methods that did not have much importance, but in some I use the repositories of the Main Entity, so they are repeated in both classes, so I would like to know if this is a "BAD PROGRAMMING PRACTICE".
The MS works perfectly, and by doing that SonarQube does not flag any alerts anymore.
CodePudding user response：
It doesn't sound like what you did is in the spirit of the warning.
Instead of splitting out a few unimportant methods, what it is really suggesting is that you figure out two or three main purposes/priorities/functionalities of the class, and then split those out into two or three separate classes. Don't do everything in the same class.
Just looking at your imports, maybe you'd want to handle financial aspects in one class (currency, payment, etc) and then handle branches and offices in another. In fact, each of those things (branch, office, payment, currency) could easily be represented as an individual class. Try to think of the various concepts as objects, and then for each such concept/object create a class that represents it.
CodePudding user response：
After you have been doing this work for several years, you will see the benefits to reducing dependencies. Especially when you start using classes from external open source libraries, where you'll need to adapt your classes to changes in code that you don't control.
It appears as though you're using Spring's "clean" architecture pattern where you have services that use repositories. Then presumably controllers will use the services.
You've decomposed one service into two services, but the naming shows you're still thinking in terms of one giant service.
Examine your use cases closely. How will the users actually be using the data? For instance, you have an ExchangeRateRepository. Is there a use case where users look up exchange rates? Then maybe you can have an ExchangeRateService that uses that repository, maybe along with the CurrencyRepository.
Think about how the data is actually requested/retrieved and how it might make sense to split up the work between multiple services. You have eight repositories. Maybe eight services are too many, but perhaps you could have three or four or five services where each service handles related requests.
Hopefully there are developers with more experience at your company that you can approach for questions like these. There's never one right answer with design, but with experience you learn to ask the right questions to help you create better designs.
Also, don't think limits from SonarQube are carved in stone. Design is all about tradeoffs. Fewer dependencies are good, but there could be a valid reason to go beyond the limit. You should be able to explain/justify to developers on your team why you chose the parameters for your design.