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?

Improve this question
6
  • 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, 2017 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
    – CHRISTIANJ
    Mar 27, 2017 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, 2017 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, 2017 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, 2017 at 11:25

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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