1

I have a method in API handler which does API validation, performs business logic and then makes a call to db. Is it a good idea to move the business logic to utility class or service class?

IMO the business logic should be moved to service as utility class are supposed to have methods which can be shared across applications. If I move the business logic to utility class then it will cause a dependency between accessor and utility which will also make it difficult to unit test.

Pls let me know if my reasoning above is correct.

  • What is your question? You have made some good arguments, so I don't see the issue. – BobDalgleish Dec 20 '18 at 13:50
  • @BobDalgleish I have presented my points and wanted to know whether they make sense? – Yug Singh Dec 20 '18 at 19:29
  • Don't move business logic to utility classes. That's a bad idea. Moving business logic to service classes is usually a good ideea, but it's procedural, not object oriented. You can read more about pros/cons of a service layer online. See for example this answer to get you started. You will then understand why Robert Bräutigam said in his answer that separating the business logic from the data it operates on is the antithesis to OOP. – Bogdan Dec 26 '18 at 16:44
0

No, it's not a good idea to move business logic to utilities and services if you want an object-oriented system.

"Utility" classes, Services, and in general separating the business logic from the data it operates on is the antithesis to object-oriented programming.

However there are other, non-object-oriented designs in Java that may fit what you want to do. Java Enterprise's "component-based" programming model (with JPA "Beans" and EJBs/CDI Beans/Services), some interpretations of Domain-Driven Design also do this.

And yes any logic will have dependency on the data it operates on. That is exactly why in object-orientation we don't separate those two, we want to have a cohesive object that is less coupled to others.

  • thanks for your answer. Could you please elaborate the statement in general separating the business logic from the data it operates on is the antithesis to object-oriented programming? What I understood from this statement is that you are referring to class state and it's associated behavior. But in my case I have API handler class which is taking an object and after validations it's performing some business logic on it. I thought it's good idea to separate the business logic to a separate class. – Yug Singh Dec 20 '18 at 19:35

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.