L'inserimento della logica di servizio nella propria classe è considerato negativo?

Question

L'inserimento della logica di servizio nella propria classe è considerato negativo?

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

0

Ad esempio, supponiamo di avere questa meravigliosa interfaccia:

public interface BestService   {
    public String whoIsAGoodService(String serviceName);
}

Per quanto riguarda l'implementazione, possiamo trovare il seguente metodo:

@Override
public String whoIsAGoodService(String serviceName)   {
    String ipFromName = this.findOutIpFromName(serviceName);
    boolean isItReallyGood = this.findOutGoodService(ipFromName);
    String intermediateResponse = this.findOutGoodServiceMessage(isItReallyGood);
    String finalResponse = this.buildFinalResponse(intermediateResponse);

    return finalResponse;
}

La domanda non riguarda la qualità del codice ⁽¹⁾. La mia domanda è:

È considerata una buona o cattiva pratica mantenerli nella classe ServiceImpl? Oppure dovremmo creare una classe chiamata BestServiceLogic per gestire tutti quei processi? Vorrei alcune informazioni su ciò che è considerato una buona pratica. Il mio punto di vista sarebbe che tende a rendere le classi di implementazione del servizio molto lunghe, raggruppando tutti i sottoprogrammi per tutti i metodi che vengono chiamati dal client. Ma vorrei alcuni obiettivi su questo.

Per qualche contesto. Sto riscrivendo il codice precedente ⁽²⁾ e vorrei trovare il modo migliore per mantenere le cose pulite e chiare a lungo termine.

Ho già letto su questa domanda ma tratta di più sull'iniezione di classe rispetto al metodo di invio attraverso le classi.

^{(1) So che potrei restituire direttamente il risultato di finalResponse e non so se usare this.method() per chiamare i membri privati come una cosa buona o cattiva (se vuoi illuminarmi su quest'ultimo, tuttavia, sarei lieto). È un esempio arbitrario e al volo.}

^{(2) non preoccuparti non , non romperò nulla, scrissi prima i test.}

object-oriented design web-services

posta Yassine Badache 29.12.2017 - 11:56

fonte

2 risposte

Leggi altre domande sui tag object-oriented design web-services

Gestire oggetti di valore complessi Modi efficaci per gestire gli avvisi dell'analizzatore statico causati dall'uso incidentale della riflessione

score 1 · Answer 1

Rispondi alla domanda nel titolo: No . Ma ci sono dei compromessi.

La prima domanda che devi porsi è questa:

Is this same exact logic needed in more than one place?

Se no, lasciatelo dov'è. Non c'è nulla di male nel trovarlo in un posto e la complessità aggiuntiva non ti darà alcun beneficio per i tuoi sforzi.

Se hai la stessa logica esatta cosparsa in posti diversi, hai il codice copia / incolla che è un incubo di manutenzione. Dovrai scavare un po 'di più.

Should my BestService be used everywhere that logic is needed, or is there a new service I need to extract?

Se è così, scopri quanto di un servizio hai davvero bisogno. È solo la scoperta IP? O ho più di un servizio qui?

In generale, composizione è una soluzione migliore dell'ereditarietà . Porta a un codice meno fragile che ha punti di estensione naturali se è necessario modificare il comportamento.

RE: this.callMethod() è in gran parte una cosa stilistica. Per i metodi non aggiunge o disambigura nulla, quindi probabilmente era solo l'abitudine dell'implementatore originale della tua classe.

Per disambiguare tra un parametro e una variabile di classe all'interno di un metodo può essere necessario. this.memberVariable = memberVariable assegna la variabile di classe al valore del parametro passato con lo stesso nome. È considerata una prassi migliore avere semplicemente una convenzione di denominazione in cui non si hanno conflitti. Puoi assegnare un nome al parametro con il suffisso In o Out a seconda della direzione (C # ha un parametro out ) oppure tutte le variabili membro ottengono un prefisso di sottolineatura ( _ ).

Dipende da cosa ti sembra più naturale:

memberVariable = memberVariableIn
_memberVariable = memberVariable

Se la tua piattaforma linguistica ha una convenzione per questo, è probabilmente una buona idea adottarla dal momento che è minore attrito per i nuovi membri del tuo team per familiarizzare con il codice.

score 0 · Answer 2

Per quello che ho capito dal tuo frammento di codice, hai esattamente uno scenario in cui puoi beneficiare del pattern Decorator . Non hai bisogno di un livello simile al servizio, tutto ciò che serve è aggiungere funzionalità al tuo oggetto iniziale.

Ci sono alcuni vantaggi se si sostituiscono i metodi private per gli oggetti reali :

È possibile eseguire test di unità contro tali oggetti.
La logica può essere condivisa attraverso il codebase senza avere un posto con tutta la logica;

Sebbene abbia senso solo estrapolare questi metodi ai decoratori, se è davvero necessario condividere il comportamento attraverso l'applicazione. Altrimenti, vorrei andare con la soluzione.