Metodi di classe che non vengono mai chiamati e tutto gestito dagli interni della classe stessa

Question

Metodi di classe che non vengono mai chiamati e tutto gestito dagli interni della classe stessa

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

1

Ho una classe nel mio codice e non sono sicuro che il design che ho implementato sia corretto o se esiste un modo migliore per farlo. La classe che ho creato ha importanti metodi utili che vengono usati da ogni istanza di quella classe. Tuttavia, il problema è che l'istanza stessa non viene mai utilizzata. La classe gestisce tutto ciò che deve essere fatto senza utilizzare l'oggetto stesso. Quindi, una volta chiamato il costruttore, non uso più l'oggetto. Gli interni della classe gestiscono tutto. Ecco un esempio di cosa intendo. È scritto in JS ma può essere applicato praticamente a qualsiasi lang.

class MyHTMLElement {
    constructor(htmlElement) {
        this.htmlElement = htmlElement;
        this.changeColorOnClick();
        this.changeBorderOnInput();
    }
    changeColorOnClick() {
        this.htmlElement.onclick = () => {
            this.htmlElement.style.color = "blue";
        }
    }
    changeBorderOnInput {
        this.htmlElement.addEventListener("input", () => {
            this.htmlElement.style.border = "2px solid green";
    }
}

Ora, una volta creato questo, tutto ciò che devo fare è chiamare new MyHTMLElement("element"); per ogni istanza di cui ho bisogno e quindi non usare mai più le funzionalità della classe. Userò ancora l'attributo htmlElement dell'istanza, ma non userò mai nessuno dei metodi. Mi sembra che non mi piaccia. C'è un modo migliore per farlo che è anche molto pulito. Grazie per il tuo aiuto.

object-oriented coding-style design object-oriented-design

posta Yang K 15.12.2018 - 20:34

fonte

3 risposte

Leggi altre domande sui tag object-oriented coding-style design object-oriented-design

Problemi di cultura preesistente durante la transizione Scrum È buona norma fornire interfacce in una libreria che verrebbe utilizzata solo per il test delle unità?

score 4 · Answer 1

Quello che stai cercando è una funzione , non un oggetto. Invece di new MyHTMLElement("element") potresti semplicemente dire modifyHtmlElement("element") che dovrebbe funzionare anche:

function modifyHtmlElement(htmlElement) {
    changeColorOnClick();
    changeBorderOnInput();

    function changeColorOnClick() {
        htmlElement.onclick = () => {
            this.htmlElement.style.color = "blue";
        }
    }

    function changeBorderOnInput {
        htmlElement.addEventListener("input", () => {
            this.htmlElement.style.border = "2px solid green";
        }
    }
}

Queste classi di soli costruttori sono solitamente un antipattern, in quanto possono essere sostituite da funzioni molto più semplici. In JavaScript esiste comunque un'interessante relazione tra funzioni, costruttori e classi, ma ciò è specifico per la lingua.

L'eccezione in cui si potrebbe davvero voler chiamare un costruttore e quindi non utilizzare l'oggetto sarebbe se il nuovo oggetto si registra da qualche parte, o se inizia a fare qualcosa in background. Per esempio. una classe che rappresenta una discussione potrebbe essere implementata in questo modo.

score 2 · Answer 2

In questo caso l'intera esistenza della tua classe è inutile. Non si aggiunge alcun valore all'htmlElement iniettato che fornisce già tutto ciò di cui si ha bisogno. Basta iscriversi direttamente ai gestori invece di inoltrarli al costruttore di una classe vuota. Anche questo è più flessibile. Tutta la tua classe ora limita l'uso di htmlElement.

score 0 · Answer 3

Il problema con questo approccio è che avrai bisogno di molte versioni di myHTMLElement per tutti i tipi di comportamento che desideri.

Per riutilizzare il codice, si vorrà utilizzare l'ereditarietà per implementare questa varietà di funzionalità. Non hai letteralmente nessun altro posto dove inserire il codice.

Fin qui So OOP. Ma in un grande progetto finirai con un albero ereditario ingestibile in cui cambiare una piccola cosa su un oggetto in alto nella gerarchia può avere conseguenze involontarie