Er der i Java klare regler for, hvornår man skal bruge de enkelte adgangsmodifikatorer, nemlig standard (pakke privat), public
, protected
og private
, mens man laver class
og interface
og håndterer arv?
Den officielle vejledning kan måske være til nytte for dig.
______________________________________________________________ | │ Class │ Package │ Subclass │ Subclass │ Subclass │ World | │ │ │ │(same pkg)│(diff pkg)│ │ | │ (same pkg)│ (diff pkg)│ | |───────────┼───────┼─────────┼──────────┼──────────┼────────| |offentligt │ + │ + │ + │ + │ + │ + │ + | |───────────┼───────┼─────────┼──────────┼──────────┼────────| |beskyttet │ + │ + │ + │ + │ + │ + │ | |───────────┼───────┼─────────┼──────────┼──────────┼────────| |no modifier│ + │ + │ + │ + │ │ │ | |───────────┼───────┼─────────┼──────────┼──────────┼────────| |private │ + │ │ │ │ │ │ │ | |___________|_______|_________|__________|__________|________| + : tilgængelig blank : ikke tilgængelig
Nem regel. Start med at erklære alting for privat. Og gå derefter over til det offentlige, efterhånden som behovet opstår og designet berettiger det.
Når du eksponerer medlemmer, så spørg dig selv, om du eksponerer repræsentationsvalg eller abstraktionsvalg. Det første er noget, du ønsker at undgå, da det vil indføre for mange afhængigheder af den faktiske repræsentation snarere end af dens observerbare adfærd.
Som en generel regel forsøger jeg at undgå at overskrive metodeimplementationer ved at underklasser; det er for nemt at ødelægge logikken. Deklarer abstrakte beskyttede metoder, hvis du har til hensigt at den skal overrides.
Brug også @Override-annotationen ved overriding for at undgå, at tingene går i stykker, når du refaktoriserer.