Datakapsling

Datakapsling är det viktigaste konceptet att förstå när man programmerar med objekt. I objektorienterad programmering handlar kapsling av data om:

• Kombinera data och hur de manipuleras på ett ställe. Detta uppnås genom staten (de privata fälten) och beteenden (de offentliga metoderna) för ett objekt.
• Tillåter bara att ett objekts tillstånd kan nås och ändras genom beteenden. Värdena som finns i ett objekts tillstånd kan då kontrolleras strikt.
• Dölja detaljerna för hur objektet fungerar. Den enda delen av objektet som är tillgänglig för omvärlden är dess beteenden. Vad som händer i dessa beteenden och hur staten lagras är dold från synen.

Verkställer datakapsling

Först måste vi utforma våra objekt så att de har tillstånd och beteenden. Vi skapar privata fält som innehåller statliga och offentliga metoder som är beteenden.

Om vi ​​till exempel utformar ett personobjekt kan vi skapa privata fält för att lagra en persons förnamn, efternamn och adress. Värdena för dessa tre fält kombineras för att göra objektets tillstånd. Vi kan också skapa en metod som heter displayPersonDetails för att visa värdena på förnamn, efternamn och adress på skärmen.

Därefter måste vi göra beteenden som får åtkomst till och ändrar objektets tillstånd. Detta kan åstadkommas på tre sätt:

• Konstruktörsmetoder. En ny instans av ett objekt skapas genom att man kallar en konstruktormetod. Värden kan överföras till en konstruktormetod för att ställa in ett initialt tillstånd för ett objekt. Det finns två intressanta saker att notera. För det första insisterar Java inte på att varje objekt har en konstruktormetod. Om det inte finns någon metod använder objektets status standardvärden för de privata fälten. För det andra kan mer än en konstruktormetod existera. Metoderna kommer att skilja sig i termer av värden som skickas till dem och hur de ställer in objektets initiala tillstånd.
• Tillbehörsmetoder. För varje privat fält kan vi skapa en offentlig metod som kommer att returnera dess värde.
• Mutatormetoder. För varje privat fält kan vi skapa en offentlig metod som sätter dess värde. Om du vill att ett privat fält ska läsas ska du inte skapa en mutatormetod för det.

Vi kan till exempel utforma personobjektet för att ha två konstruktormetoder. Den första tar inga värden och ställer helt enkelt in objektet till att ha ett standardläge (dvs. förnamnet, efternamnet och adressen skulle vara tomma strängar). Den andra anger initialvärden för förnamnet och efternamnet från värden som skickas till det. Vi kan också skapa tre accessormetoder som heter getFirstName, getLastName och getAddress som helt enkelt returnerar värdena för motsvarande privata fält. Skapa ett mutatorfält som heter setAddress som ställer in värdet på det privata adressfältet.

Slutligen döljer vi implementeringsdetaljer för vårt objekt. Så länge vi håller oss för att hålla statliga fält privata och beteenden offentliga finns det inget sätt för omvärlden att veta hur objektet fungerar internt.

Skäl för datakapsling

De viktigaste skälen för att använda datakapsling är:

• Att hålla ett objekts tillstånd lagligt. Genom att tvinga ett privat fält av ett objekt som ska modifieras med en offentlig metod, kan vi lägga till kod i mutator- eller konstruktormetoderna för att se till att värdet är lagligt. Föreställ dig till exempel att personobjektet också lagrar ett användarnamn som en del av dess tillstånd. Användarnamnet används för att logga in på den Java-applikation vi bygger men är begränsad till en tio teckenlängd. Vad vi kan göra är att lägga till kod i användarnamnets mutatormetod som ser till att användarnamnet inte är inställt på ett värde längre än tio tecken.
• Vi kan ändra implementeringen av ett objekt. Så länge vi håller de offentliga metoderna på samma sätt kan vi ändra hur objektet fungerar utan att bryta koden som använder den. Objektet är i huvudsak en "svart ruta" till koden som kallar det.
• Återanvändning av föremål. Vi kan använda samma objekt i olika applikationer eftersom vi har kombinerat data och hur de manipuleras på ett ställe.
• Varje objekts oberoende. Om ett objekt är felkodat och orsakar fel är det enkelt att testa och fixa eftersom koden finns på ett ställe. Faktum är att objektet kan testas oberoende av resten av applikationen. Samma princip kan användas i stora projekt där olika programmerare kan tilldelas skapandet av olika objekt.