[java] design: wanneer interne class?

[Alarmnummer]

Is er een guideline voor wanneer je een interne en wanneer een externe class gaat maken?

ps: uitleg over interne en externe klassen is niet nodig

[mbravenboer]

Tja.... goede vraag .

In Java is er de bijzondere situatie dat inner-classes ook daadwerkelijke lexical-scope hebben. Dat heb je in C# (volgens mij) bijvoorbeeld niet. Een instantie van een Java inner-class 'leeft' dus echt in het omringende object. Op basis van deze omschrijving probeer ik altijd de keuze te maken voor al dan niet inner-classes. Als een object 'in' een ander object leeft en je deze klasse nooit buiten dit object zou gebruiken maar ik er weleens een inner-class van.

Verder gebruik ik nooit anonieme inner-classes en eigenlijk ook zo weinig mogelijk normale inner-classes. Meestal doe ik het alleen voor wat listeners, die ik weiger te implementeren in de hoofd-klasse. Een aparte inner-class kan dan wel een aardige oplossing zijn omdat je die in deze situatie typisch nooit ergens anders gebruikt.

Over het algemeen is het wellicht gewoon gemakzucht .

[Alarmnummer]

ik gebruik ze ook vooral voor listeners zodat je inderdaad je hoofdobject niet loopt te verzieken. Hmmm.. jammer dat er niet een echte guideline voor is.

En ik heb er net even een paar anonieme innerclasses ingezet voor de oefening (heb ze nog niet eerder gebruikt). Maar vind eerlijk gezegd een losse klasse een stuk makkelijker.

Als je een anonieme innerclass gaat vergelijken met de scope van een variable zit er meer logica in dan een normale innerclass. Je bent tenslotte alleen op dat punt geinteresseerd in die classe en verder niet meer en dat kan je niet met een losse innerclass naar voren brengen.

De leesbaarheid is inderdaad alleen naadje

code:

public class SaveAction extends AbstractAction
    public SaveAction(){
        super(
            "Save",
            new ImageIcon(
                 DatabaseEditor.class.getClassLoader().getResource("com/jph/bla/Save.png")
             )
        );
        
        m_multiDatabaseEditorModel.addPropertyChangeListener(
            MultiDatabaseEditorModel.CURRENT_DATABASE,
            new PropertyChangeListener(){
                public void propertyChange(PropertyChangeEvent pce){
                    Database database = (Database)pce.getNewValue();
                    setEnabled(database!=null);
                }
            }
        );

        
        setEnabled(false);
    }

    public void actionPerformed(ActionEvent e){
        save(false);
    }
}

[mbravenboer]

Alarmnummer: Hmmm.. jammer dat er niet een echte guideline voor is.

Het is theoretisch denk ik niet zo interessant en ook niet echt geaccepteerd als een waardevolle toevoeging van een OO-taal (behalve dat het wellicht makkelijk is oid). Ik denk dat je het daarom niet terug ziet in boeken als 'refactoring' of 'design patterns'.

[mbravenboer]

Alarmnummer: En ik heb er net even een paar anonieme innerclasses ingezet voor de oefening (heb ze nog niet eerder gebruikt). Maar vind eerlijk gezegd een losse klasse een stuk makkelijker.

Inderdaad... anonieme inner-classes zuigen gewoon .

Als je een anonieme innerclass gaat vergelijken met de scope van een variable zit er meer logica in dan een normale innerclass.

Mwah, waarom? Ik vind het eerder vrij vreemd dat je bij final lokale variabelen kunt komen vanuit die anonieme inner-class...

Je bent tenslotte alleen op dat punt geinteresseerd in die classe en verder niet meer en dat kan je niet met een losse innerclass naar voren brengen.

Hum... dat denk ik toch niet... Als je echt netjes bezig bent moet je bijvoorbeeld je listeners afmelden. Daarvoor moet je een referentie naar je instantie bewaren.