Quero padronizar meus processos de mapeamento para seguir um esquema específico. Por isso, introduzi algumas interfaces genéricas que ajudam a reduzir o esforço ao escrever novos mapeadores para novos tipos. Aqui está a interface para os tipos:
import lombok.NonNull;
public interface MappableCyclic<IN extends MappableCyclic<IN, OUT>, OUT extends MappableCyclic<OUT, IN>>
{
void beforeMapping(@NonNull IN in, @NonNull OUT out, @NonNull ReferenceCycleTracking context);
void afterMapping(@NonNull IN in, @NonNull OUT out, @NonNull ReferenceCycleTracking context);
}
ReferenceCycleTrackingé uma implementação típica para um contexto mapstruct para evitar recursão infinita ao mapear objetos com dependências cíclicas. Além disso, há uma superinterface genérica para mapeadores:
public interface MappableCyclicMapper<IN extends MappableCyclic<IN, OUT>, OUT extends MappableCyclic<OUT, IN>>
{
@NonNull OUT map(@NonNull IN in, @NonNull @Context ReferenceCycleTracking context);
@BeforeMapping default void beforeMapping(
@NonNull IN in,
@NonNull @MappingTarget OUT out,
@NonNull @Context ReferenceCycleTracking context)
{
out.beforeMapping(out, in, context);
}
@AfterMapping default void afterMapping(
@NonNull IN in,
@NonNull @MappingTarget OUT out,
@NonNull @Context ReferenceCycleTracking context)
{
out.afterMapping(out, in, context);
}
@NonNull Class<OUT> outType();
@NonNull OUT create(IN in);
/**
* object factory should be called by mapstruct during generated {@link #map(MappableCyclic, ReferenceCycleTracking)}
* implementation
*/
@ObjectFactory default @NonNull OUT lookupOrCreate(@NonNull IN in, @NonNull ReferenceCycleTracking context)
{
OUT out = context.get(in, outType());
if (out == null)
{
out = create(in);
context.put(in, out);
}
return out;
}
}
E finalmente aqui está a interface do mapeador para dois dos meus tipos mapeáveis:
@Mapper interface Map_TaskGroup_EntityDTO_EntityJPA extends MappableCyclicMapper<TaskGroupEntityDTO, TaskGroupEntityJPA>
{
Map_TaskGroup_EntityDTO_EntityJPA INSTANCE = Mappers.getMapper(Map_TaskGroup_EntityDTO_EntityJPA.class);
@NonNull TaskGroupEntityJPA map(@NonNull TaskGroupEntityDTO input, @NonNull @Context ReferenceCycleTracking context);
@Override default @NonNull Class<TaskGroupEntityJPA> outType() { return TaskGroupEntityJPA.class; }
@Override default @NonNull TaskGroupEntityJPA create(TaskGroupEntityDTO in) { return new TaskGroupEntityJPA(in.name()); }
@ObjectFactory
@Override default @NonNull TaskGroupEntityJPA lookupOrCreate(
@NonNull TaskGroupEntityDTO taskGroupEntityDTO, @NonNull ReferenceCycleTracking context)
{
return MappableCyclicMapper.super.lookupOrCreate(taskGroupEntityDTO, context);
}
}
Eu esperava que o mapstruct usasse o @ObjectFactorymétodo fornecido na superinterface, mas isso não acontece. Então, tentei ajudar o mapstruct com um método de fábrica de objetos adicional na subinterface acima. No entanto, a implementação para essa interface gerada pelo mapstruct ignora meus métodos de fábrica de objetos:
@Override
public TaskGroupEntityJPA map(TaskGroupEntityDTO input, ReferenceCycleTracking context) {
TaskGroupEntityJPA target = context.get( input, TaskGroupEntityJPA.class );
if ( target != null ) {
return target;
}
if ( input == null ) {
return null;
}
String name = null;
TaskGroupEntityJPA taskGroupEntityJPA = new TaskGroupEntityJPA( name );
context.put( input, taskGroupEntityJPA );
beforeMapping( input, taskGroupEntityJPA, context );
afterMapping( input, taskGroupEntityJPA, context );
return taskGroupEntityJPA;
}
Como posso ter certeza de que meus métodos de fábrica de objetos não serão mais ignorados?
Use uma classe abstrata dedicada para a Fábrica de Objetos.
Métodos padrão em interfaces são uma espécie de "complementos opcionais" em Java. Eles não fazem parte da hierarquia de herança da mesma forma que métodos em classes abstratas. Por esse motivo, o MapStruct não os trata de forma tão confiável. Ele precisa decidir se deve incluir o método padrão no mapeador gerado, copiar a lógica ou simplesmente ignorá-lo. Isso pode causar comportamentos estranhos ou inconsistências.
As coisas ficam ainda mais complicadas se você tiver várias interfaces com métodos padrão sobrepostos ou conflitantes. O Java em si não lida bem com isso — ele deixa a cargo do programador decidir qual implementação usar. Portanto, quando o MapStruct tenta gerar código nesses cenários, ele pode ter dificuldades devido à ambiguidade.
Esse problema é especialmente problemático quando métodos padrão são usados para lógica crítica, como criação de objetos ou lógica de fábrica (
@ObjectFactory). Às vezes, o MapStruct os inclui no mapeador gerado, às vezes não — isso não é confiável. Por outro lado, classes abstratas evitam toda essa confusão. Elas são tratadas como parte de uma cadeia de herança concreta, portanto, o MapStruct sempre sabe que deve substituir métodos abstratos ou chamar métodos concretos ao gerar código. Isso garante que tudo funcione de forma consistente, especialmente para recursos complexos como mapeamentos cíclicos ou fábricas de objetos personalizadas.Em suma, classes abstratas são simplesmente mais previsíveis e confiáveis para MapStruct. Elas não vêm com todos os comportamentos opcionais e ambíguos que os métodos padrão em interfaces podem introduzir.
Classe base abstrata abaixo
Implementação do Mapper
O motivo pelo qual o método de fábrica de objetos não é levado em consideração não é por ser um método ```padrão``` em uma interface. Em vez disso, o parâmetro ```ReferenceCycleTracking``` não possui a anotação ```@Context``` no meu exemplo.