Vantaggi di queste raccomandazioni nell'ooprogrammazione usando Java

Question

Vantaggi di queste raccomandazioni nell'ooprogrammazione usando Java

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

-4

Di seguito sono riportate le raccomandazioni della sezione 5.1 di questo saggio .

While Java is not a pure object-oriented language, it is possible to program in a pure object-oriented style by obeying the following rules:

1) Classes only as constructors A class name may only be used after the keyword new.

2) No primitive equality The program must not use primitive equality (==). Primitive equality exposes representation and prevents simulation of one object by another.

3) In particular, classes may not be used as types to declare members, method arguments or return values. Only interfaces may be used as types. Also, classes may not be used in casts or to test with instanceof.

This is generally considered good object-oriented style

Ad esempio,

sotto parte del codice jdk non segue il terzo punto sopra menzionato:

restituisce il tipo di metodo toArray .

public Object[] toArray() {
     //whatever
   }

in java.util.AbstractCollection .

o

restituisce il tipo di toString() nethod.

public String toString() {
        //whatever
    }

sotto la parte del codice jdk segue il terzo punto sopra:

public Iterator<E> iterator() {
        return new Itr();
    }

Quali vantaggi troviamo nel seguire queste raccomandazioni? È possibile inserire alcuni schemi di progettazione (automaticamente) seguendo tali raccomandazioni?

object-oriented design java interfaces design-patterns

posta overexchange 05.07.2015 - 14:27

fonte

2 risposte

Leggi altre domande sui tag object-oriented design java interfaces design-patterns

Separa le classi per ogni responsabilità? [chiuso] Requisiti di sistema nello schema dei casi d'uso [chiuso]

score 3 · Answer 1

Ciò che ottieni seguendo i suoi consigli è la capacità di accettare qualsiasi oggetto indipendentemente dall'implementazione purché implementa correttamente un'interfaccia. Non c'è niente di speciale in questo ed è una tecnica comunemente usata. Come sottolinea la carta, ciò che si perde è:

La possibilità di limitare le variabili a una classe specifica, che conta quando la correttezza è importante. Ad esempio, se SecurityManager di Java accetta l'interfaccia CharSequence anziché la classe String , puoi sovvertire i controlli di sicurezza passando una stringa mutabile.
La capacità dei metodi di esaminare i dettagli di implementazione di due oggetti. Ad esempio, l'interfaccia Set non può avere un metodo di unione set ragionevole perché non c'è alcuna garanzia che due Set s abbiano la stessa implementazione. L'unico modo per calcolare l'unione di due Set s è il modo ingenuo e inefficiente: iterare attraverso entrambi.

score 0 · Answer 2

La mia modesta opinione è che questo tipo di affermazioni audaci può essere sbagliato, con coraggio.

Non sarà possibile utilizzare una classe statica. E non consentirà alcuni modi di creare un singleton per esempio.
A volte è utile e aiuta l'algoritmo. Ma leggi questo post che ti aiuterà a prendere la tua decisione. link
Le classi sono ok in molti casi. Le interfacce sono buone se si pensa che si sostituirà l'implementazione di una classe e anche le interfacce consentono di eseguire un'iniezione di dipendenza che aiuta il test dell'unità. Quindi non sono d'accordo nemmeno con 3.