Template Method pattern mit "geschützten Methoden"
-
Hallo,
ich habe Code von etwa dieser Struktur:
public abstract class Executor { final public void execute() { init(); //... shutdown(); } abstract void init(); abstract void shutdown(); }
Da es in meinem konkreten Fall keinen Sinn macht, init() oder shutdown() außerhalb von execute() aufzurufen, sondern eher sogar Mist dabei rauskommen kann, würde ich gerne init() und shutdown() vor diesen Aufrufen von außen (d.h. außerhalb execute()) schützen.
So wie es da steht, können natürlich noch Klassen im selben package die Methoden aufrufen, d.h. das geht so nicht. Mit private davor würde es auch nicht gehen, da abstract und private sich ausschließen. Public geht sowieso nicht, klar, und protected ist natürlich auch nicht zweckmäßig.
Gibt es irgendeine Möglichkeit wie ich das Problem lösen kann? Ich würde meinen, dass so etwas häufiger vorkommt, also was sind die "best practices" damit umzugehen?
Danke schonmal.
Mfg,
Christoph
-
Warum ist protected nicht zweckmäßig? Ich denke es ist genau was du suchst...
MfG SideWinder
-
Weil bei protected immer noch innerhalb des packages auf die Methoden zugegriffen werden kann.
-
(das würde vllt in der Praxis nicht soo dramatisch sein, müssen die anderen Programmierer halt "nur" ein wenig aufpassen und Kommentare lesen, aber mich interessiert ob man das irgendwie besser erreichen kann)
-
ChristophEff schrieb:
Weil bei protected immer noch innerhalb des packages auf die Methoden zugegriffen werden kann.
Nein, nur in abgeleiteten Klassen ist ein Zugriff möglich.
MfG SideWinder
-
SideWinder schrieb:
Nein, nur in abgeleiteten Klassen ist ein Zugriff möglich.
JLS 6.6.2 sagt, dass Du unrecht hast.
-
Also hier steht meine Version von protected (siehe Tabelle): http://download.oracle.com/docs/cd/E17409_01/javase/tutorial/java/javaOO/accesscontrol.html
Da das von sun/oracle ist, denke ich es wird stimmen.
-
Mit diesem Ansatz kannst du deine Methoden nicht schützen. Aber wenn du selber ein Package schreibst, dann sollte das ja kein Problem sein. Dann müssen die Entwickler innerhalb des Packages halt wirklich bescheid wissen. Dem eigenen Package sollte man dann halt trauen können
Mfg ica