Alternatywa dla instanceof

0

Witam. Mam następujący problem z refactoringiem kodu wykonującego transformacje różnych niepowiązanych ze sobą typów. Obecnie wykonywane to było w mniej więcej następujący sposób:

 class Container{
        TargetObject1 targetObject1;
        TargetObject2 targetObject2;
    }

 public void convert(Object o){
  if(o instanceof SourceObj1){
        container.targetObject1 = transformerSourceObj1.transformSourceObj1((SourceObj1) o);
    } else if(o instanceof SourceObj2){
        container.targetObject2 = transformerSourceObj2.transformSourceObj2((SourceObj2) o);
    }

Transformery ani obiekty nie są ze sobą w żaden sposób powiązane, tzn. nie implementują wspólnego interface'u. Pierwszą rzeczą, którą chciałbym wykonać, jest ustawienie wspólnego typu dla nich. Coś w rodzaju:

public interface ITransformer<T, U> {
    T transform(U source);
}

@ObjectTransformer(targetClass = SourceObj1.class)
public class TransformerAObj implements ITransformer<TargetObject1, SourceObj1> {

    public TargetObject1 transform(SourceObj1 source) {
        TargetObject1 targetObject1 = new TargetObject1();
        targetObject1.targetField = source.sourceField + "123456789";

        return targetObject1;
    }
}

Kolejną sprawą jest uniknięcie długiej listy intanceof. Czy jest sposób, aby w tym przypadku użyć adnotacji, ale nie na obiekcie źródłowym, gdyż ten pochodzi z zewnętrznej biblioteki, a na obiekcie, na który następuje transformacja? Może coś jak:

 @Target(ElementType.TYPE)
public @interface ObjectTransformer {
    Class<?> targetClass();
}

Najlepiej byłoby, gdyby na podstawie adnotacji do określonej dynamicznej struktury(np. mapy) dodawał ITransformer, gdzie kluczem byłaby klasa obiektu źródłowego. Niestety na przeszkodzie stoi generycznośc powyższego interface'u. Czy jest możliwość uzyskania dużej płynności w dodawaniu nowych transformerów dla typów bez rozbudowywania listy if..else if najlepiej z wykorzystaniem adnotacji? Dodam także, że dość ważna jest w tym wypadku wydajność, gdyż metoda ta jest często wywoływana i użycie refleksji za każdym razem może być za bardzo obciążające.

0

Za mocno kombinujesz. Napisałeś ** nie implementują wspólnego interface'u**
No to stwórz taki interfejs. Przecież tu i tu wykonuje się metoda transformSource. To znaczy, że mają część wspólną i niech taki będzie interfejs. Wtedy polimorfizm i jechana

0

Właśnie tak napisałem w poście - utworzyłem wspólny interface, lecz typ zwracany jak i przyjmowany przez metodę transormSource jest dla każdej implementacji inny. Z tego powodu użyłem generyków. O ile typ zwracany jest po mojej stronie, więc mogę go sprowadzić do wspólnego mianownika, to typ z którego następuje konwersja jest z zewnętrznej biblioteki i typy te nie mają połączenia za wyjątkiem powiązania biznesowego.

0

Możesz napisać coś takiego:

 public interface ITransformer<T, U> {
	Class<T> srcClass();
	Class<U> dstClass();
    T transform(U source);
}

Czyli transformer udostępnia też jawnie informacje z jakiej klasy na jaką robi mapowanie. Na podstawie tego możesz zrobić bi-mapę i metodę z 2 parametrami Class<?> która wyciągnie z niej wartość, lub w przypadku null (czyli brak odpowiedniego transformatora) rzuci wyjątek.

0

pierwsza sprawa, jak w kodzie zamierzasz uzyc instanceof i nie jest to override equalsa to wiedz ze zapewne gdzies twoj kod jest "zle" napisany. od czasów generyków nie miałem potrzeby uzyc Object'a w moim kodzie, nie mowie jesli jakis legacy framework tego wymagał.

kolejna sprawa, to sa toole jak orika czy inne do transformacji obiektow

1 użytkowników online, w tym zalogowanych: 0, gości: 1