Sono nuovo di OOP/PHP. Qual è la praticità di visibilità ed estensibilità nelle classi?

Question

Sono ovviamente nuovo di zecca per questi concetti. Semplicemente non capisco perché limiti l'accesso a proprietà o metodi. Sembra che vorresti solo scrivere il codice in base ai risultati previsti. Perché dovresti creare un metodo privato invece di non chiamare quel metodo? E 'per la creazione iterativa di oggetti (se lo sto affermando correttamente), una situazione di sviluppatori multipli (non rovinare il lavoro di altre persone), o solo per non rovinare il tuo lavoro per errore?

Answer 1

Tutto si riduce all'incapsulamento. Ciò significa nascondere gli interni della classe e prendersi cura di ciò che fa. Se si desidera avere una classe di elaborazione della carta di credito, non si cura veramente 'come' elabora la carta di credito. Vuoi solo essere in grado di andare: $creditCardProcessor->charge(10.99, $creditCardNumber); e aspettarti che funzioni.

Rendendo alcuni metodi pubblici e altri privati ​​o protetti, lasciamo un modo di accesso per gli altri in modo che sappiano da dove è sicuro chiamare il codice. I metodi e le variabili pubblici sono chiamati "interfaccia".

Per qualsiasi classe, si dispone di un'implementazione . Questo è il modo in cui la classe svolge il suo dovere. Se è una classe che fa smoothie, come la classe aggiunge gli ingredienti, quali ingredienti aggiunge, ecc. Fanno tutti parte dell'implementazione. Il codice esterno non dovrebbe conoscere e/o preoccuparsi dell'implementazione.

L'altro lato della classe è l'interfaccia . L'interfaccia è i metodi pubblici che lo sviluppatore della classe intendeva chiamare con codice esterno. Ciò significa che dovresti essere in grado di chiamare qualsiasi metodo pubblico e funzionerà correttamente.

Answer 2

Creiamo metodi privati ​​in modo che i consumatori delle nostre classi non debbano preoccuparsi dei dettagli di implementazione - possono concentrarsi sulle poche cose che le nostre classi forniscono per loro.

Inoltre, siamo obbligati a considerare ogni possibile uso dei metodi pubblici. Rendendo i metodi privati, riduciamo il numero di funzioni che una classe deve supportare e abbiamo più libertà di modificarle.

Supponiamo di avere una classe Queue - ogni volta che un chiamante aggiunge un elemento alla coda, potrebbe essere necessario aumentare la capacità della coda. A causa dell'implementazione sottostante, l'impostazione della capacità non è banale, pertanto è possibile suddividerla in una funzione separata per migliorare la leggibilità della funzione Enqueue. Poiché ai chiamanti non interessa la capacità di una coda (lo gestisci per loro), puoi rendere il metodo privato: i chiamanti non vengono distratti dai metodi superflui, non devi preoccuparti che i chiamanti facciano cose ridicole alla capacità e puoi modificare l'implementazione ogni volta che vuoi senza rompere il codice che utilizza la tua classe (purché imposti ancora la capacità entro i casi d'uso limitati definiti dalla tua classe).

Answer 3

Ci sono diversi motivi per usare l'incapsulamento, uno dei più forti è: immagina di usare una libreria grande e complicata scritta da qualcun altro. Se ogni oggetto non fosse protetto, potresti inconsciamente accedere o modificare valori che lo sviluppatore non ha mai inteso manipolare in quel modo.

Nascondere i dati rende il programma più facile da concettualizzare e più facile da implementare.

Answer 4

Si tratta di incapsulamento. I metodi sono privati ​​che fanno il lavoro del grugnito interiore mentre espongono le funzioni aggraziate che rendono le cose facili. Per esempio. potresti avere una funzione $ product-> insert() che utilizza 4 funzioni interne per convalidare un oggetto db singleton, rendere la query sicura, ecc. - quelle sono funzioni interne che non devono essere esposte e se chiamate, potrebbero rovinare altre strutture o flussi che tu, lo sviluppatore, hai messo in atto.

Answer 5

I tuoi ultimi due punti sono abbastanza precisi - non hai bisogno di più sviluppatori per avere i tuoi contenuti in disordine. Se lavori su un progetto abbastanza a lungo, ti accorgerai di aver dimenticato molto di ciò che hai fatto all'inizio.

Uno dei motivi più importanti per nascondere qualcosa è che è possibile in modo sicuro cambiare in seguito. Se un campo è pubblico, e diversi mesi dopo lo vuoi cambiare in modo che ogni volta che il campo cambia, succede qualcos'altro, sei nei guai. Perché era pubblico, non c'è modo di sapere o ricordare quanti altri posti hanno avuto accesso direttamente a quel campo. Se è privato, hai la garanzia che non venga toccato al di fuori di questa classe. Probabilmente hai un metodo pubblico avvolto attorno ad esso, e puoi facilmente cambiare il comportamento di quel metodo.

In generale, più cose rendi pubbliche, più devi preoccuparti della compatibilità con altri codici.

Answer 6

Ad esempio, il metodo privato/protetto può far parte di una classe chiamata in un altro metodo (pubblico). Se quella parte è chiamata in più metodi pubblici, ha senso. Eppure non vuoi che questi metodi vengano chiamati da nessun'altra parte.

È lo stesso con le proprietà di classe. Sì, puoi scrivere classi pubbliche, ma qual è il divertimento?

Answer 7

una situazione sviluppatore multipla (Non rovinare il lavoro di altre persone), o semplicemente in modo da non rovinare il proprio lavoro fare accidentalmente?

Principalmente queste due cose. Rendere pubblico un metodo dice "questo è il modo in cui la classe dovrebbe essere usata dai suoi clienti", affermando in privato "questo è un dettaglio di implementazione che può cambiare senza preavviso e di cui i clienti non dovrebbero preoccuparsi" E costringe i clienti a seguirlo consigli.

Una classe con pochi, ben documentati metodi pubblici è molto più facile da usare da parte di qualcuno che non ha familiarità con esso (che potrebbe essere il suo autore originale, guardandolo per la prima volta in 6 mesi) di uno in cui tutto è pubblico, inclusi tutti i piccoli dettagli sull'implementazione di cui non ti importa.

Answer 8

Semplifica la collaborazione, dici agli utenti delle tue classi quali parti non devono cambiare così spesso e puoi garantire che il tuo oggetto sarà in uno stato significativo se usano solo metodi pubblici.

Non è necessario essere così rigidi come distinguere tra privato/pubblico/qualunque (intendo applicato dalla lingua). Ad esempio, in Python, questo è realizzato da una convenzione di denominazione. Sai che non dovresti scherzare con qualcosa contrassegnato come non pubblico.