Pattern da utilizzare quando solo poche funzioni hanno una dipendenza?

Question

Pattern da utilizzare quando solo poche funzioni hanno una dipendenza?

#1 da (3 voti)

0

Ho una classe come questa:

class X {
  X (databaseconn, httpclient) {
    this.httpclient = httpclient
    this.databaseconn = databaseconn
  }

  public func1(a, b) {
    // ...
  }

  public func2(x, y, z) {
    // ...
  }

  // ...

  public funcN(p, q, r) {
    // ...
  }
}

Ci sono pochissimi metodi nella classe che operano sul% co_de iniettato (direttamente o tramite un altro metodo). Creare e iniettare, quindi, mi sembra inutile e dispendioso.

Quale pattern dovrebbe essere seguito quando c'è una dipendenza usata raramente come httpclient in questo caso?

dependency-injection design-patterns

posta user2064000 27.11.2016 - 08:27

fonte

1 risposta

Leggi altre domande sui tag dependency-injection design-patterns

Come dovrei preparare il mio SVG per la produzione? [chiuso] Design pattern per classe di servizio java [chiuso]

score 3 · Accepted Answer

Devi decidere se httpclient è una dipendenza dell'oggetto o dei metodi - e questo dipende dalla classe .

Ad esempio, supponiamo tu abbia una classe Message che ha bisogno di smtpclient per il suo metodo send . Diciamo anche che abbiamo una classe MailReceiver che controlla le nuove email e ha bisogno di smtpclient per il suo metodo poll . Gli altri metodi di entrambe le classi non hanno bisogno di smtpclient . È una dipendenza dell'oggetto o dei metodi?

Nel caso di Message , è una dipendenza del metodo. Un messaggio di posta elettronica è un messaggio di posta elettronica ancora prima di inviarlo e potresti volerlo inviare tramite più client SMTP. Quindi non passi smtpclient a c'tor: lo passi direttamente al metodo send .

Per MailReceiver , d'altra parte, è una dipendenza dell'oggetto. Un destinatario della posta deve ricevere le email da qualche parte. Quindi passi smtpclient a c'tor e poll ce l'ha appena.

Non pensare in termini di "inutili" e "sprechi" - pensa che cosa ha senso per il modello a oggetti.