Decidere tra obj-func () e func (obj)

Question

Decidere tra obj-func () e func (obj)

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

4

Stavo pensando a questo quando stavo iniziando a impostare un codice per un nuovo progetto: ci sono delle regole per quando un metodo dovrebbe essere parte di un oggetto, e quando dovrebbe essere una funzione indipendente che prende un oggetto come parametro?

EDIT: come indicato in un commento, questo può dipendere dalla lingua. Stavo lavorando in C ++ quando mi è venuto in mente, anche se sono un problema in un certo numero di lingue (e mi piacerebbe comunque vedere le risposte che riguardano loro).

object-oriented coding-style

posta GSto 15.02.2011 - 23:01

fonte

3 risposte

Leggi altre domande sui tag object-oriented coding-style

Quali pratiche di sicurezza dovresti sapere quando scrivi software? [chiuso] Quale estensione di file utilizzi per il tuo template / visualizza i file in PHP? [chiuso]

score 9 · Answer 1

Se non appartiene concettualmente alla classe, dovrebbe essere una funzione autonoma. (potrebbe anche essere che appartenga logicamente alla classe, ma ci sono così tante funzioni simili il fatto di mantenerli tutti come membri gonfierebbe l'interfaccia di classe e comprometterebbe l'incapsulamento: in questo caso è meglio tracciare un confine tra il "cerchio esterno" delle funzioni di utilità e il "cerchio interno" delle funzioni di interfaccia di classe core, il primo essendo indipendente funzioni implementate in termini di quest'ultimo.)
Se appartiene alla classe ma il suo primo parametro può essere un'istanza di un tipo diverso, dovrebbe essere una funzione autonoma (possibilmente friend ) (un tipico esempio è operator + ) .

(Scott Meyers lo mette più elegantemente in efficace terza edizione C ++ , elemento 24: dichiara non -membri le funzioni quando le conversioni di tipo devono essere applicate a tutti i parametri )
se deve essere virtuale o utilizza parti private della classe, deve essere un membro.
In caso contrario ~~dovrebbe essere una funzione membro~~ è in qualche modo una questione di preferenza .

Nota: gli esempi di codice che mostri mi fanno presumere che il linguaggio sia C ++. In molti altri linguaggi come Java, la domanda è priva di significato perché non ci sono funzioni autonome.

score 3 · Answer 2

Preferisco le funzioni non membro, non amico: In che modo le funzioni non membri migliorano l'incapsulamento di Scott Meyers :

When it comes to encapsulation, sometimes less is more.

[...] If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function. That decision increases class encapsulation. When you think encapsulation, you should think non-member functions. [...]

score 0 · Answer 3

Il principio di responsabilità singola spesso aiuta, quando devi decidere se qualche metodo o più ampio di alcune funzionalità appartiene ad un oggetto.

Si noti inoltre che se alcune funzionalità correlate a qualche oggetto non appartengono a un oggetto, potrebbe comunque avere senso incapsularlo in un altro oggetto, come in other->func(obj) .

class Mouth {
    void say(String msg);
    void sayHello(Person to);
    void sayBye(Person to);
}

Ora il 2 ° e il 3 ° metodo in realtà chiamano solo il metodo say e in realtà non appartengono alla responsabilità di Mouth .

interface Out {
    void say(String msg);
}
class Mouth implements Out {
    void say(String msg);
}
class Phrases {
    void new(Language language);
    void sayHello(Person to, Out over);
    void sayBye(Person to, Out over);
}

Naturalmente potrebbe essere più sensato passare un Out -instance a Phrases dopo la costruzione. O per avvolgerlo in un'altra classe. O qualsiasi altra cosa Ma sicuramente non ha senso avere quei metodi in Mouth , come suggerisce l'SRP.