I have a service (S) that receives an object of type 's', this service will be called by several classes (maybe 6) and each class has their own object a,b,c, etc. with the information necessary to fill object 's'. There is no big logic when setting the values of 's', just some s.setPhone(a.getPhone()) calls.

Would it be good practice to create a single class with one method for each object a,b,c and all of them return an object of type 's'? That way everything would be in a single file that would be called from the classes that will use the new service to create the object 's'.


This doesn't sound like a good idea:

  • your single "conversion class" would depend on all the classes A, B, C, that could ever potentially need to be converted to an s.
  • everywhere you invoke your service, you would then need your conversion class, and therefore have a dependency to a lot of other classes you might not need.
  • so you would have in the end a very tight coupling, which is no desired: every time you'd change one of the A, B, C classes, it could possibly require a change in your conversion class. Same, every time you create a new class to be converted to s.

Keep the interface segregation and the single responsibility principles in mind.

I'd rather propose to create an abstract interface with a single conversion method, and make A, B, C classes implement this interface.

  • 1
    Wouldn't the SRP be broken if I make each class also responsible of creating the object s (with the logic it might have) apart from whatever they are doing now? The advantage that I saw with the single class aproach was that if the object s changed, everything would be in one place instead of many – joe Aug 6 '18 at 8:56
  • @joe Excellent remark! This is a common misunderstanding: The "single" of SRP is meant for the reason to change and not for the function of the class. Here an article of Uncle Bob, the "inventor" of SRP, that explains it very well: 8thlight.com/blog/uncle-bob/2014/05/08/… – Christophe Aug 6 '18 at 10:11

Just create an instance of s in each of your class (a, b, c, ...) accordingly. Don't add a new layer of abstraction which is useless.

Example (pseudo code):

class A
    S.someService(new s(a.getPhone(), a.getAddress(), "m"));
class B
    S.someService(new s(b.getPhone(), "no-address", b.getSex()));
class C
    S.someService(new s("000-000-000", c.getAddress(), c.getSex()));

It makes sense to have a single place where the object of your class is constructed. It makes it much easier to reason about your code and follow a flow of an object through your code.

For simple data structures, that can simply be its own constructor, but in your case, there's quite a lot of logic and other objects involved. Consider looking into construction patterns such as Builder pattern.

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.