I Java, er det klare regler for når man skal bruke hver av tilgangsmodifikatorene, nemlig standard (package private), public
, protected
og private
, mens man lager class
og interface
og håndterer arv?
Den offisielle veiledningen kan være til nytte for deg.
______________________________________________________________ | │ Klasse │ Pakke │ Underklasse │ Underklasse │ Verden │ │ (samme pkg) │ (diff pkg) │ (samme pkg) | │ │ │ (same pkg)│ (diff pkg)│ | │ │ (same pkg)│ (diff pkg)│ (same pkg)│ (diff pkg) |───────────┼───────┼─────────┼──────────┼──────────┼────────| |public │ + │ + │ + │ + │ + │ + | |┼┼| |───────────┼───────┼─────────┼──────────┼──────────┼────────| |protected │ + │ + │ + │ + │ + │ | |┼┼┼| |───────────┼───────┼─────────┼──────────┼──────────┼────────| |no modifier│ + │ + │ + │ │ │ │ | |───────────┼───────┼─────────┼──────────┼──────────┼────────| |private │ + │ │ │ │ │ │ | |___________|_______|_________|__________|__________|________| + : tilgjengelig blank : ikke tilgjengelig
Enkel regel. Begynn med å erklære alt som privat. Og gå deretter videre mot offentligheten etter hvert som behovene oppstår og utformingen tilsier det.
Når du eksponerer medlemmer, spør deg selv om du eksponerer representasjonsvalg eller abstraksjonsvalg. Det første er noe du vil unngå, da det vil introdusere for mange avhengigheter av den faktiske representasjonen i stedet for av dens observerbare oppførsel.
Som en generell regel prøver jeg å unngå å overstyre metodeimplementeringer ved å underklasse; det er for lett å skru opp logikken. Deklarer abstrakte beskyttede metoder hvis du har tenkt at den skal overstyres.
Bruk også @Override-kommentaren når du overstyrer for å hindre at ting går i stykker når du refaktorerer.