Modul-Erstellung: public, protected und private functions

Hallo,

es gibt bestimmt dazu bestimmt schon eine Antwort im Forum, aber ich habe nichts verbindliches gefunden.

functions können ja als public, protected und private deklariert sein.

Der Unterschied ist mir grundsätzlich klar (denke ich), aber nicht, ob ich das im IPS-Kontext richtig anwende.

Ich gehe davon aus, das alle Funktionen in einem Modul, die von „extern“ (also Scripts etc) aufgerufen werden sollen, public sein können und sollten, der Rest private.

Mir begegnen aber immer wieder Funktionen, die protected sind, bei denen ich aber nicht versteh, was an diesen Funktionen ander ist. public sind z.B. i.d.R. Create() oder ApplyChanges(), protected z.B. ProcessHookData() oder SetValue().

Welche Funktionen müssen/sollten (wenn überhaupt) protected sein?

Bei den diversen Module, die es so gibt, habe ich keine nachvollziehbare Systematik erkannt.

Es ist nur eine Verständnisfrage, ich habe kein funktionelles Problem. Für einen informativen Hinweis oder eine kurze Aufklärung wäre ich dankbar.

Danke
Christian

Alle public Methoden müssen erstens den Typ der Variablen deklariert haben und sind für einen Nutzer in IP-Symcon in Ereignissen oder z.B. über Befehle testen (CTRL+E) aufrufbar. Die Variablen Deklaration ist wichtig, weil sonst IP-Symcon in Formularen wie Ereignissen nicht weis was es passend zum Variablentyp einblenden soll.

Methoden die protected sind sollen eben nicht von außen für den Nutzer aufrufbar sein, weil es keinen Sinn macht ProcessHookData oder ähnliches aufrufen zu können, die Daten werden ja direkt von IP-Symcon an die Methode übergeben. Da Variablen in Instanzen Read Only sind, gilt dies ab IPS 5 auch für Variablen von PHP Modulen, daher ist auch SetValue protected.

Daten an andere Instanzen sollten nach Best Practice zur PHP-Modul Erstellung über den Datenfluss übergeben werden und nicht durch aufrufen einer public Methode.

Zusätzlich:

Es gibt spezielle Public Methoden wie Create, Destroy, GetConfigurationForm usw… welche nur IPS intern nutzt.
Diese werden entsprechend ‚gefiltert‘ so dass ein User sie nicht sieht. Da aber IPS sie ansprechen muss, sind sie public.

protected müssen alle Methoden sein, wo du eine Methode aus der Klasse IPSModule überschreiben willst, wenn diese ebenfalls protected also nicht public ist (private kann man man nie überschreiben).
Wie z.B. ProcessHookData.

Für eigene Methoden ist es so lange egal ob du nun protected oder private nutzt, bis du anfängst auch hier mit Vererbung zu arbeiten.

Also

MyModul extends MyModulClassBase

MyModulClassBase extends IPSModule

Dann kann MyModul nur auf protected Methoden MyModulClassBase und IPSModule zugreifen oder diese Überschreiben.
Aber niemals auf private, diese dürfen nur innerhalb der eigene Klasse aufgerufen werden.

Details dazu sind aber in der PHP-Doku besser beschrieben :smiley:

Michael

Hallo,

ja, soweit klar

auch klar

Aha-Effekt :D, nun verstehe ich, warum diese Funktionen nicht zu sehen sind, das hat mich nämlich echt gewundert.

okidoki, dann ist das so, wie ich die PHP-Doku dazu verstanden habe. Solange ich nicht Funktionen von mir selbst überlagere, könnte ich die alle private machen.
Mir sind die Internas vom IPS noch nicht so ganz klar :banghead:
Daher war ich mir nicht sicher, ob spezielle Funktionen nicht doch vom IPS wieder überlagert werden (warum auch immer).

Jetzt bin ich wieder ein bisschen schlauer.

Danke und schön Tag noch
Christian

Naja… Internas ist gut :wink:
Es ist halt auch Vererbung von IPSModule welche du bei Protected überschreibst.
Ebenso mit Public Create, wo du ja die Create Methode von IPSModule überschreibst.
Welche Sichtbarkeit gefordert ist, steht in der PHP-SDK Doku.
Alles was dort so als Methode auftaucht, ist für den User auch nicht sichtbar und wird gefilltert. IPS kennt ja diese Methoden und weiß was du damit machen willst :slight_smile:
Michael