Jede gute Beispiele für Erben von einer konkreten Klasse?

Sie haben oft eine Skelett-Implementierungen für eine Schnittstelle I. Wenn Sie bieten Erweiterbarkeit ohne abstrakte Methoden (z.B. über Haken), ist es vorzuziehen, eine nicht-abstrakte Skelett-Klasse, weil Sie instanziieren können es.

Ein Beispiel wäre ein Weiterleitung wrapper-Klassen, um in der Lage sein, um vorwärts zu einem anderen Objekt einer konkreten Klasse C Umsetzung I, z.B. die Aktivierung Dekoration oder einfache code-Wiederverwendung von C zimmerreserviereung, ohne das Sie Erben von C. Sie finden ein solches Beispiel in Effektive Java Element 16, favor composition over inheritance. (Ich will nicht es hier zu posten wegen der Urheberrechte, aber es ist wirklich einfach die Weiterleitung an alle Methodenaufrufe I auf den umschlossenen Umsetzung).

Einen sehr häufigen Fall, ich denken kann, ist eine Ableitung von grundlegenden Steuerelemente der Benutzeroberfläche, wie Formen, Textfelder, comboboxes, usw.. Sie sind vollständige, konkrete, und auch in der Lage zu stehen; jedoch die meisten von Ihnen sind auch sehr basic, und manchmal Ihre Standard-Verhalten ist nicht, was Sie wollen. Praktisch niemand würde beispielsweise die Verwendung einer Instanz von einer unverfälschten Form, es sei denn, möglicherweise wurden Sie schafft eine völlig dynamische UI-layer.

Beispielsweise in ein Stück software, die ich schrieb vor kurzem erreichten Reifegrad (was bedeutet, dass ich nicht genügend Zeit, um den Fokus in Erster Linie auf der Entwicklung von it 🙂 ), fand ich, ich brauchte, um hinzuzufügen, "lazy loading" - Funktion für ComboBoxes, so würde es sich nicht nehmen, 50 Jahre (in computer-Jahren) für das erste Fenster zu laden. Ich musste auch die Fähigkeit, automatisch filtern Sie die verfügbaren Optionen in einer ComboBox basierend auf was gezeigt wurde, in einem anderen, und schließlich brauchte ich einen Weg, um "Spiegel" ein Kombinationsfeld-Wert in andere editierbare Steuerung, und nehmen Sie eine änderung in einer Kontrolle passieren die anderen als gut. Also erweiterte ich die basic ComboBox geben Sie diese zusätzlichen Eigenschaften, und erstellt zwei neue Arten: LazyComboBox, und dann weiter, MirroringComboBox. Beide basieren auf der völlig intakt ist, konkrete ComboBox-Steuerelement, nur überschreiben einige Verhaltensweisen und hinzufügen von ein paar andere. Sie sind nicht sehr lose gekoppelt und damit nicht so SOLIDE, aber die zusätzliche Funktionalität ist generisch genug, dass, wenn ich musste, ich konnte umschreiben, dass diese beiden Klassen von Grund auf neu zu tun, den gleichen job, vielleicht besser.

Dies ist ein Beispiel für eine aktuelle Umsetzung, ich bin Unternehmen.

In OAuth 2-Umgebung, da die Dokumentation ist noch im Entwurfsstadium, die Spezifikation hält zu ändern (wie von Zeit zu schreiben, wir sind in der version 21).

So, ich hatte zu verlängern, meine konkrete AccessToken Klasse, um Platz für die verschiedenen access-Token.

In früheren Entwurf war, gab es keine token_type Feld gesetzt, so dass die eigentliche access token ist wie folgt:

public class AccessToken extends OAuthToken {

    /**
     * 
     */
    private static final long serialVersionUID = -4419729971477912556L;
    private String accessToken;
    private String refreshToken;
    private Map<String, String> additionalParameters;

    //Getters and setters are here
}

Nun, mit Access-Token zurückgibt token_type habe ich

public class TokenTypedAccessToken extends AccessToken {

    private String tokenType;
    //Getter and setter are here...
}

So, ich kann beide und der Endbenutzer wird nicht klüger. 🙂

In der Zusammenfassung: Wenn Sie möchten, eine benutzerdefinierte Klasse, die hat die gleiche Funktionalität, die von Ihrer konkreten Klasse ohne änderung der Struktur der konkreten Klasse, ich schlage vor, die Ausweitung der konkreten Klasse.

Anderen Anwendungsfall wäre das das Standardverhalten zu überschreiben:

Können sagen, es ist eine Klasse, die verwendet standard Jaxb parser für das Parsen

public class Util{

    public void mainOperaiton(){..}
    protected MyDataStructure parse(){
        //standard Jaxb code 
    }
} 

Nun sagen, das ich verwenden möchte einige unterschiedliche Bindung (Sagen XMLBean) für die parsing-operation,

public class MyUtil extends Util{

    protected MyDataStructure parse(){
      //XmlBean code code 
    }
}

Jetzt kann ich mit der neuen Bindung mit Wiederverwendung von code, der super-Klasse.

Viele Antworten, aber ich dachte, ich würde meine eigenen $0.02.

Ich überschreiben konkreten Klassen selten, aber unter bestimmten besonderen Umständen. Mindestens 1 bereits erwähnt, bei der framework-Klassen sind so konzipiert, verlängert werden. 2 zusätzliche, in den Sinn kommen mit einigen Beispielen:

1) Wenn ich im Spiel das Verhalten einer konkreten Klasse. Manchmal möchte ich ändern, wie die konkrete Klasse funktioniert oder ich möchte wissen, Wann eine bestimmte Methode aufgerufen wird, so kann ich etwas auslösen. Oft konkrete Klassen definieren Sie eine hook-Methode, deren einzige Verwendung ist für die Unterklassen diese Methode überschreiben.

Beispiel: Wir überschrieb MBeanExporter denn wir müssen in der Lage sein, um die Registrierung einer JMX-bean:

public class MBeanRegistrationSupport {
    //the concrete class has a hook defined
    protected void onRegister(ObjectName objectName) {
    }

Unserer Klasse:

public class UnregisterableMBeanExporter extends MBeanExporter {
    @Override
    protected void onUnregister(ObjectName name) {
        //always a good idea
        super.onRegister(name);
        objectMap.remove(name);
    }

Hier ist ein weiteres gutes Beispiel. LinkedHashMap ist entworfen, um Ihre removeEldestEntry Methode überschrieben.

private static class LimitedLinkedHashMap<K, V> extends LinkedHashMap<K, V> {
    @Override
    protected boolean removeEldestEntry(Entry<K, V> eldest) {
        return size() > 1000;
    }

2) Wenn eine Klasse teilt sich eine erhebliche überlappung mit der konkreten Klasse, außer für einige Verbesserungen in der Funktionalität.

Beispiel: Mein ORMLite Projekt behandelt anhaltenden Long Objekt-Felder und long primitive Felder. Beide haben fast die identische definition. LongObjectType bietet alle Methoden, die beschreiben, wie die Datenbank beschäftigt sich mit long Felder.

public class LongObjectType {
    //a whole bunch of methods

während LongType überschreibt LongObjectType und nur Verbesserungen eine einzelne Methode zu sagen, mit der "primitiven".

public class LongType extends LongObjectType {
    ...
    @Override
    public boolean isPrimitive() {
        return true;
    }
}

Hoffe, das hilft.

Ich fange an zu fühlen, dass es fast keine situation, wo Erben von einer konkreten Klasse angemessen ist.

Dies ist ein "fast". Schreiben Sie eine applet ohne Verlängerung Applet oder JApplet.

Hier ist ein z.B. von der applet-info. Seite.

/* <!-- Defines the applet element used by the appletviewer. -->
<applet code='HelloWorld' width='200' height='100'></applet> */
import javax.swing.*;

/** An 'Hello World' Swing based applet.

To compile and launch:
prompt> javac HelloWorld.java
prompt> appletviewer HelloWorld.java  */
public class HelloWorld extends JApplet {

    public void init() {
        //Swing operations need to be performed on the EDT.
        //The Runnable/invokeLater() ensures that happens.
        Runnable r = new Runnable() {
            public void run() {
                //the crux of this simple applet
                getContentPane().add( new JLabel("Hello World!") );
            }
        };
        SwingUtilities.invokeLater(r);
    }
}

Im Allgemeinen, ist es besser, Erben von einer abstrakten Klasse als von einer konkreten Klasse. Eine konkrete Klasse muss eine definition für seine Darstellung der Daten, und einige Unterklassen müssen eine andere Darstellung. Da eine abstrakte Klasse nicht haben, um eine Darstellung der Daten, Zukunft Unterklassen verwenden können, jede Darstellung ohne Angst vor dem Konflikt mit der, der Sie geerbt hat.
Noch nie fand ich eine situation, wo ich fühlte, Beton inheritence notwendig ist. Aber es könnte einige Situationen für konkrete inheritence, besonders, wenn Sie die Abwärtskompatibilität zu Ihrer software. In diesem Fall u möglicherweise haben sich darauf spezialisiert, eine class A aber Sie wollen es, konkret zu sein als Ihre ältere Anwendung möglicherweise verwenden.

aus der gdata-Projekt:

com.google.gdata.client.Service ist konzipiert als Basis-Klasse, die angepasst werden können für bestimmte Arten von GData services.

Service javadoc:

Den Service Klasse stellt eine client-Verbindung zu einem GData-service. Es kapselt alle Protokoll-level-Interaktionen mit dem GData server und fungiert als helper-Klasse für höhere level-Einheiten (feeds, Einträge, etc), die invoke-Vorgänge auf dem server und verarbeiten Ihre Ergebnisse.

Diese Klasse stellt die Basis-Ebene gemeinsame Funktionalität für den Zugriff auf GData-service. Es ist auch entworfen, um als Basis-Klasse, die angepasst werden können für bestimmte Arten von GData services. Beispiele von unterstützten Anpassungen gehören:

Authentifizierung - Implementierung einer benutzerdefinierten Authentifizierungs-Mechanismus für services, die eine Authentifizierung erfordern und verwenden Sie etwas anderes als eine HTTP-basic-oder-digest-Authentifizierung.

Erweiterungen - definieren Sie die zu erwartenden Erweiterungen für die Futtermittel -, Einreise-und andere Arten ein, verbunden mit einem service.

Formate - definieren weitere benutzerdefinierte Ressourcen-Repräsentationen, die möglicherweise verbraucht oder produziert von service-und client-Seite Parser und Generatoren, um Sie zu behandeln.

Tun Sie das zum Beispiel in der GUI-Bibliotheken. Es macht nicht viel Sinn, Erben von einer reinen Komponente und delegieren Sie an eine Tafel. Es ist wahrscheinlich viel easyer zu Erben von der Platte direkt.