Passaggio dalla classe astratta all'interfaccia

5

Ho una classe astratta che ha tutti i metodi astratti tranne uno che costruisce oggetti delle sottoclassi. Ora il mio mentore mi ha chiesto di spostare questa classe astratta su un'interfaccia.

Avere un'interfaccia non è un problema se non con il metodo usato per costruire oggetti di sottoclasse. Dove dovrebbe andare questo metodo adesso?

Inoltre, ho letto da qualche parte che le interfacce sono più efficienti delle classi astratte. È vero?

Ecco un esempio delle mie classi

abstract class Animal {
    //many abstract methods
    getAnimalobject(some parameter) {
        return //appropriate subclass 
    }
}

class Dog extends Animal {}
class Elephant extends Animal {}
    
posta nischayn22 26.06.2012 - 15:46
fonte

3 risposte

12

Questo metodo di costruzione dovrebbe essere inserito in una nuova classe di fabbrica.

In object-oriented computer programming, a factory is an object for creating other objects. It is an abstraction of a constructor, and can be used to implement various allocation schemes. For example, using this definition, singletons implemented by the singleton pattern are formal factories.

A factory object typically has a method for every kind of object it is capable of creating. These methods optionally accept parameters defining how the object is created, and then return the created object.

Factory objects are used in situations where getting hold of an object of a particular kind is a more complex process than simply creating a new object. The factory object might decide to create the object's class (if applicable) dynamically, return it from an object pool, do complex configuration on the object, or other things...

    
risposta data 26.06.2012 - 15:52
fonte
4

Il tuo design è un po 'non ortodosso, Animal::getAnimalobject() è ereditato su Dog e Elephant inutilmente. Quello che devi fare è:

  1. Sposta tutte le funzioni astratte nell'interfaccia,
  2. le tue classi Dog e Elephant implementano un'interfaccia Animal ,
  3. Continua a crearli con un metodo factory, come fai attualmente.

... e probabilmente vorrai rinominare Animal (la classe) in AnimalFactory .

    
risposta data 26.06.2012 - 15:53
fonte
0

Also, I read somewhere that interfaces are more efficient than abstract classes. Is this true?

No, nessuno dei due è più efficiente dell'altro.

L'astrazione ti offre cambiamenti di comportamento ereditari migliori della classe, dal momento che devi solo apportare modifiche in un posto. Laddove, le interfacce consentono di separare il comportamento di una classe in più descrizioni.

Questo perché una classe può estendere solo una classe astratta. Quindi, tutto il comportamento della classe astratta viene ereditato, dove una classe può implementare più interfacce che consente a tale classe di rappresentare più comportamenti.

Having an interface is no problem except with the method used to construct subclass objects. Where should this method go now?

Forse qualcosa di simile.

interface Animal {
  getAnimalobject(parameter);
}

class Dog implements Animal {
   function getAnimalobject(parameter) { return .... }
}

class Elephant implements Animal {
   function getAnimalobject(parameter) { return .... }
}

Un sacco di motivi per cui questo è meglio dell'astrazione, ma non voglio davvero scriverli tutti. Ecco i miei principali motivi per le interfacce sull'astrazione.

Principali motivi per utilizzare l'interfaccia

  1. Le classi astratte possono creare problemi di gestione degli oggetti e della memoria. Per esempio; se si crea una classe astratta chiamata "Elenco" e aveva un metodo astratto chiamato "Rimuovi". Quando implementi il tuo metodo "Rimuovi", dovresti eliminare la memoria o tenerla? Semplicemente non sai cosa sta facendo la classe base, o cosa farà in futuro. Se qualcuno modifica la classe base per gestire l'elenco in modo diverso, è probabile che tu possa rompere le cose nella tua classe.

  2. Le interfacce sono facili da usare nei test. Creare oggetti mock di un'interfaccia è molto più semplice della creazione di un oggetto fittizio di classi astratte.

  3. Gli oggetti possono implementare più interfacce ma solo una classe astratta.

  4. Le modifiche a una classe astratta possono causare una cascata di errori su più classi, o peggio solo un piccolo errore nascosto in una classe usata raramente.

risposta data 26.06.2012 - 20:16
fonte

Leggi altre domande sui tag