Quando ho iniziato a programmare l'incapsulamento era un concetto difficile da ingoiare. Forse perché mi sono concentrato sul lavoro da solo piuttosto che in una squadra. Coprire tutti i modificatori è troppo per questo forum. Quindi mi concentrerò sull'incapsulamento, privato e pubblico.
Mentre, questo non è l'unico motivo per incapsulare ... Posso illustrare con un esempio.
L'incapsulamento ha davvero iniziato a dare più senso quando ho iniziato a lavorare in una squadra. Quando lavori con un altro sviluppatore, vuoi dividere le attività. Supponiamo che ti venga assegnato il compito di creare uno strumento di posta elettronica. Per prima cosa, tu e il dev2 state insieme e discutete di cosa avrete bisogno:
- Un Emailer richiede che dati e funzionalità funzionino correttamente.
Dati - : Da, A, Oggetto, Corpo, Messaggio, Allegati
Funzionalità - : Send (), GetSmtpServer ()
L'attività diventa la classe o "oggetto". I dati diventano proprietà. La funzionalità diventa funzioni.
public class Emailer
{
public string From
public string To
public string Subject
public string Body
public string Message
public string[] Attachments
public Email(){}
public Send()
{
//functionality
}
private GetSmtpServer()
{
//functionality
}
}
Puoi chiedere, "Perché ho reso privato GetSmtpServer ()?"
Perché l'altro sviluppatore vuole sapere come usare l'Email. Non ha bisogno di sapere tutti i miei dettagli nitidi. Quindi, non ha bisogno di vedere GetSmtpServer() . Questo è il motivo per cui l'ho reso privato.
Infine, l'incapsulazione raggruppa elementi simili in un'unica unità. Questo rende il tuo codice auto-documentante. In altre parole, posso guardare la classe chiamata "Emailer" e avere una buona idea di cosa dovrebbe fare. Quando vedo "Invia ()" posso indovinare che invierà un'e-mail.
D'altra parte, se aggiungo a Emailer un metodo chiamato "CreateInventory ()", non sarebbe ovvio come funzioni questa funzione. Non ci sono ulteriori dettagli su questo, oltre a ciò è l'abuso di incapsulamento e un altro argomento.