Perché voglio che questa classe estenda un'interfaccia e qual è il modello di progettazione giusto per questo?

Question

Perché voglio che questa classe estenda un'interfaccia e qual è il modello di progettazione giusto per questo?

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

0

Supponiamo di avere un'interfaccia Employee e ci sono molte classi che la implementano, come Bob , Joe e Mary , nessuna delle quali può essere cambiata.

public interface Employee{
  public void work()
}

public class Mary implements Employee{
  public void work(){
    //Mary's implementation of work
  }
}

Devo creare una classe Manager che sia un wrapper per un oggetto Employee . Quindi il costruttore per Manager prende un oggetto di tipo Employee

Public class Manager{
private Employee employee;

  public Manager(Employee employee){
     this.employee = employee;
  }

  public void work(){
    this.employee.work()
  }

  public void manage(){
     //my implementation of manage
  }


}

Quando viene creato un oggetto Manager , dovrebbe avere tutti i metodi del% co_de sottostante più alcuni extra. La maggior parte dei metodi dell'oggetto Employee sottostante non verrà sovrascritta (vedere Employee ), e quindi penso che dovrei estendere work . Ma una classe non può estendere un'interfaccia. Attualmente, sto lavorando per dichiarare ciascuno dei metodi Employee nella classe Employee e averli semplicemente chiamati il metodo Manager corrispondente. Ma sembra che sia inutile e che si rompa se l'interfaccia Employee cambia.

Poiché l'estensione di un'interfaccia non è consentita, qual è il modello di progettazione corretto per ciò che sto cercando di fare?

java design-patterns

posta Jared K 09.06.2016 - 18:41

fonte

3 risposte

2

In questo caso non hai bisogno di ereditarietà, hai bisogno di composizione:

public interface Manager {
    void manage();
}

public class Mary implements Employee, Manager{
    public void work(){
        //Mary's implementation of work
    }

    public void manage(){
        //manage
    }
}

Java consente alle classi di implementare interfacce multiple ed è una buona linea guida: Perché dovrei preferire la composizione all'ereditarietà?

Se non puoi letteralmente cambiare la classe Mary , dovresti creare un oggetto wrapper come te, che agirà come un adapter per le istanze della classe Employee.

Non penso che sia necessario estendere l'interfaccia Employee, poiché non hai indicato che avrà bisogno di un metodo work() .

risposta data 10.06.2016 - 00:42

fonte

0

Hai detto Devo creare una classe Manager che sia un wrapper per un oggetto Employee Scopo del wrapper esattamente quello che hai descritto, avvolge qualche altro comportamento con i propri metodi.

Penso che la tua classe Manager debba implementare l'interfaccia Employee .

Public class Manager implements Employee
{
    private Employee employee;

    public Manager(Employee employee)
    {
        this.employee = employee;
    }

    public void work()
    {
        this.employee.work();
    }

    public void manage()
    {
        //my implementation of manage
    }
}

In questo caso Manager comportamento di avvolgimento della classe dell'interfaccia Employee ed estendilo con il proprio comportamento del gestore.

risposta data 09.06.2016 - 18:53

fonte

Leggi altre domande sui tag java design-patterns

Backend come servizio o distribuzione del mio back-end Creazione di un filtro facet utilizzando Elasticsearch

score 0 · Accepted Answer

Il modo in cui lo stai facendo è fondamentalmente il solito modo di farlo in un linguaggio statico. Probabilmente dovresti dichiarare il tuo Manager per implementare Employee , ma a parte questo non c'è davvero un modo migliore per ottenere il risultato che desideri.

In alcuni linguaggi tipizzati dinamicamente (es. Ruby o Smalltalk) c'è un'altra alternativa: puoi implementare un metodo che viene chiamato se al tuo oggetto viene inviato un messaggio non riconosciuto (cioè viene chiamato con un metodo che non conosce) e puoi quindi inoltrare il messaggio all'oggetto di destinazione. Java non ha modo di farlo.