6

Recently, we have started to migrate a spring application to java 8. The application is divided into 3 layers, rest controllers, service and the repository layer. Our 'architect' proposed that our service layer, always accept a mapper function e.g.

public <T> Optional<T> getCompany(int companyId, Mapper<S,T> mapper) 

His reason is flexibility - to allow the calling class to format the result in whatever or it wish to.

I do disagree with the the proposal, as i think it's just abuse of the feature. At the same time, i dont want to give the impression that im not willing to adapt new features / concepts if they really bring benefit.

My question is, is the above proposal valid or just an abuse of a java 8 feature?

  • 1
    Would you object to using a mapper class rather than a Mapper function? i.e. is your objection to using a Java 8 feature or to the whole idea - because your response in each case needs to be very different, and objecting to a Mapper when what you're really objecting to is over-engineering will be at best a waste of time. – Philip Kendall Mar 27 '17 at 5:46
  • 1
    I dont object the use of a Mapper class, im fine with it being 'transformed' outside of the function. I just object the idea of passing a mapping function as an argument my reason being, it's not the service's layer function to translate data around – HelloWorld Mar 27 '17 at 5:53
  • 7
    Why not simply return S, and if the caller needs a T, then he/she can map the result using a Mapper<S, T>? What happens when you do not need to map? (Presumably, you must pass the identity function...) Having the caller code (optionally) apply the mapping is just as flexible as your architect's proposed solution. – Andres F. Mar 27 '17 at 5:59
  • 2
    @ChristianJ Would you object to a mapper class being passed in to the service layer? I'm guessing you would, in which case this is nothing to do with Java 8. – Philip Kendall Mar 27 '17 at 6:02
  • 1
    @AndresF. -- Your comment could easily be an accepted answer. Not returning S seems to be a major flaw of the "getCompany" method. If the S object is so "taken for granted" that it needs to be in the method signature than convolving "retrieving S" with "transforming S into T" is bad practice. – Ivan Mar 29 '17 at 11:25
13

If you actually mean something like

public <S super Company, T> Optional<T> getCompany(int companyId, Mapper<S,T> mapper)

and the only function of the mapper is to transform the final result of the getCompany implementation, this seems very unneccesary to me. You could also have

public Optional<Company> getCompany(int companyId)

and if you really need to transform the result, a call would look like getCompany(someid).map(mapper) instead of getCompany(someid, mapper) in your API design. That transfers the intention much better and removes the often unneccesary clutter to pass Function.identity() as mapper if you don't want to actually transform the result.

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.