OOP Mehrfache Vererbung von abstrakten Klassen

[skummy]

Hallo Forum,

meine Frage bezieht sich eher auf Code und OOP-Style. Das Programm funktioniert und macht im Prinzip was es soll.

Ich habe eine abstrakte Basis-Klasse:

public abstract class XMLResponse  {

    protected InputStream in;
    protected String specialChild;

    public void execute() throws JDOMException, IOException {
        this.parseResponse();
    }

    public abstract List<?> getParseObjects();

    public void setResponseContent(InputStream in) {
        this.in = in;
    }

    public void setSpecialChild(String specialChild) {
        this.specialChild = specialChild;
    }

    protected abstract void parseResponse() throws JDOMException, IOException;
}

Diese Basis-Klasse implementiert die Methoden zum Setzen der Eigenschaften. Dann existierten zwei weiteren Klassen, die von dieser Basisklasse erben:

public abstract class XMLMasterDataResponse extends XMLResponse {


    protected List xmlItems;    

    @Override
    public List<?> getParseObjects() {
        return xmlItems;
    }

    @Override
    protected void parseResponse() throws JDOMException, IOException {
        XMLParser parser = new XMLMasterData(in);
        Element items = parser.getSpecialChildParserElement(specialChild);
        this.createItemObjects(items);        
    }

    public abstract void createItemObjects(Element items);

}

Die andere Klasse, die von dieser erbt implementiert nur die Methode parseResponse() auf eine andere Art und Weise.

Die konkrete Klassen, die einfach von XMLMasterDataResponse erben, brauchen nur noch die Methode createItemObjects(Element items) implementieren:

public class XMLMasterDataBillOfMaterial extends XMLMasterDataResponse {

    @Override
    public void createItemObjects(Element items) {
        xmlItems = new ArrayList<XMLBillOfMaterialStructure>();
        List<Element> item = items.getChildren();
        for(Element i: item) {
            XMLBillOfMaterialStructure billItem = new XMLBillOfMaterialStructure();
            billItem.setItemIDSupplier(i.getChild("ItemIDSupplier").getText());
            billItem.setArticleIDSupplier(i.getChild("ArticleIDSupplier").getText());
            billItem.setDescription(i.getChild("Description").getText());
            xmlItems.add(billItem);
        }
    }
}

Um andere Werte in die xmlItems-Liste einzufügen, muss immer nur eine andere Klasse erstellt werden, die createItemObjects(Element items) implementiert.

Erzeugt und konfiguriert werden die einzelnen Objekte dann so:

       XMLResponse response = new XMLMasterDataBillOfMaterial();
       response.setSpecialChild("BillOfMaterial");
       response.setResponseContent(in2);
       response.execute();

Normalerweise übergebe ich das response Objekt noch einer Methode sendXML(XMLResponse response), die die Funktionen response.setResponseContent(in2) und response.execute() ausführt.


Kurz und Knapp...kann man das so machen? Für Tipps und Hinweise wäre ich sehr dankbar.


Grüße,
Sandro

 

[RySa]

Die andere Klasse, die von dieser erbt implementiert nur die Methode parseResponse() auf eine andere Art und Weise.

Irgendwie kann ich hier, "die andere Klasse" nicht finden

Aber von dem was ich hier sehen kann, sieht es eigentlich ganz ok aus. Da kann man sich noch streiten, ob 1-2 von den Methoden nicht im Interface festgelegt werden sollten, aber sonst müsste es ok sein 🙂

 

[SlaterB]

sieht grundsätzlich schlüssig aus,
man sollte nur überlegen es nicht zu übertreiben,
vielleicht zeigen andere Klassen noch mehr Verwendung, bisher könnte es genausogut auch einfach

public abstract class XMLResponse  {
   public List<Element> parse(InputStream in, String specialChild) throws ..;
}

lauten, mit entsprechenden Unterklassen,

die gesparten Zeilen
> XMLParser parser = new XMLMasterData(in);
> Element items = parser.getSpecialChildParserElement(specialChild);
erscheinen marginal, mehrfaches
> xmlItems = new ArrayList<XMLBillOfMaterialStructure>();
könnte man auch noch vermeiden, aber naja

 

[skummy]

@SlaterB

Okay, vielleicht hätte ich den letzen Absatz vom Post doch ausführlicher schreiben sollen:

Es existiert eine weitere Klasse, die ein (noch nicht fertig konfigurtiertes) Objekt vom Datentyp XMLReponse entgegennimmt und erst dort ausführt.

public class SendXML {

public void sendXML(XMLResponse response) throws IOException, JDOMException {
 
//... erstelle in2 Objekt

            response.setResponseContent(in2);
            response.execute();

//... weiteres
            List responseList = response.getParseObjects();
}

    public List<?> getResponseList() {
        return responseList;
    }

Bevor ich das response Objekt an die sendXML Methode übergebe, mache ich noch folgendes:

        XMLResponse response = new XMLMasterDataBillOfMaterial();
        response.setSpecialChild("BillOfMaterial");
        SendXML send = new SendXML();
        send.sendXML(response);
        send.getResponseList();

        XMLResponse response2 = new XMLMasterDataBillOfMaterialVersions();
        response2.setSpecialChild("Items");
        SendXML send2 = new SendXML();
        send2.sendXML(reponse2);
        send2.getResponseList();

Mit deiner Methode, müsste ich das specialChild Element mit an sendXML übergeben, was ich aber vermeiden wollte, da die Klasse SendXML davon eigentlich nichts wissen muss, oder?

Grüße

 

[SlaterB]

sicher, was hilft das hilft

 

[Marco13]

Nur aus Neugier, weil da ein paar Trigger-Worte gefallen sind, und nur, falls das kein "Betriebsgeheimnis" ist: Kannst du ein paar Stichworte über den "groben Zusammenhang" nennen, in dem du das schreibst?

 

[skummy]

@Marco13

Hmmm...es ist im Grunde genommen ein WebService, der per REST XML-Dateien an einen ESB sendet, empfängt und aufbereitet (parsing).
Die Funktionien für die einzelnen Clients werden per WSDL-Datei bereitstellt. Da der REST Endpunkt allein sehr unflexibel und viel Overhead hat, exisitiert dieser WebService dazwischen, der Request und Response für die Clients sehr stark vereinfacht.

Oder wolltest du auf etwas komplett anderes hinaus?

 

[Marco13]

Ja, nämlich das ganz übergeordnete, worum es in dem Projekt an sich geht (quasi nicht-technisch...)