2012-04-05 5 views
1

Ich habe ein Domänenmodell in PHP geschrieben, und einige meiner Klassen (Entitäten in einem Aggregat) haben öffentliche Methoden, die nie außerhalb des Aggregats aufgerufen werden sollten.Gibt es ein @ visibility-Paketkonzept in PHPDoc/PHPStorm?

PHP nicht das Paket Sichtkonzept, so fragt ich mich, ob es irgendeine Art von standardisierter Art und Weise ist @package und @visibility package in dem Docblocks zu definieren, und ein statisches Analyse-Tool zu haben, die Verletzungen des Bericht würde Sichtbarkeitsbereich.

Ich probiere gerade PHPStorm aus, was ich bis jetzt sehr gut gefunden habe, also frage ich mich, ob diese Software diese Funktion unterstützt; Wenn nicht, kennen Sie ein Tool zur statischen Codeanalyse?

Antwort

0

Bisher scheint PHPSstorm diese Funktion nicht zu bieten.

0

Die nächste Parallele zu dieser Denkrichtung, die ich in der PHP-Fähigkeit sehe, ist die Verwendung eines "geschützten" Bereichs für diese Methoden. Zugegeben, das erfordert die Verwendung von Vererbung, um Zugriff auf die geschützten Elemente zu gewähren. In meinen Jahren, in denen ich phpDocumentor verwaltet habe, bin ich noch nie auf etwas anderes gestoßen, das versucht, diese Art von "Paketumfang" nachzustellen, an die ich mich aus meinen Java-Tagen erinnere.

+0

Wenn ich über * Aggregate * spreche, bestehen sie tatsächlich aus mehreren Objekten, die mit ihren öffentlichen Methoden miteinander kommunizieren müssen. Ich bin mir der Einschränkungen von PHP bewusst und versuche nicht, Java wirklich nachzuahmen, sondern versuche lediglich, das PHP-Codeanalyse-Tool anzudeuten, damit es mögliche falsche Verwendungen meiner Klassen melden kann! – Benjamin

0

Wenn die Entitäten in Ihrem Aggregatstamm nicht geändert werden können, ohne den Aggregatstamm zu durchlaufen, müssen Sie als einziges Steuerelement steuern, dass die Entität ein privates oder geschütztes Member wird, damit alle Änderungen an der Entität ausgeführt werden durch das Aggregat.

class RootEntity { 
    private $_otherEntity; 
    public function DoSomething() { 
     $this->_otherEntity->DoSomething(); 
    } 
    public function setOtherEntity(OtherEntity $entity) { 
     $this->_otherEntity = $entity; 
    } 
} 

Jemand kann noch immer tun:

$otherEntity = new OtherEntity(); 
$otherEntity->DoSomethingElse(); 
$rootEntity->setOtherEntity($otherEntity); 

Obwohl, ich glaube, man den Zauber __call verwenden könnte() -Methode Einstellung des _otherEntity überall zu verbieten, außer während der Bauphase. Dies fällt unter insgesamt Hack Kategorie :)

class RootEntity { 
    private $_otherEntity; 
    private $_isLoaded = false; 

    public function __call($method, $args) { 
     $factoryMethod = 'FactoryOnly_'.$method; 
     if(!$this->_isLoaded && method_exists($this,$factoryMethod) { 
      call_user_func_array(array($this,$factoryMethod),$args 
     } 
    } 
    public function IsLoaded() { 
     $this->_isLoaded = true; 
    } 
    protected function FactoryOnly_setOtherEntity(OtherEntity $otherEntity) { 
     $this->_otherEntity = $otherEntity; 
    } 
} 

also von dort, wenn Sie das Objekt erstellen, können Sie $ agg-> setOtherEntity ($ otherEntity) von Ihrem Werk oder Repository aufrufen. Wenn Sie mit dem Erstellen des Objekts fertig sind, rufen Sie IsLoaded() auf. Von dort aus wird niemand mehr in der Lage sein, eine neue OtherEntity in die Klasse einzuführen und muss die öffentlich verfügbaren Methoden auf Ihrem Aggregat verwenden.

Ich bin mir nicht sicher, ob Sie das eine "gute" Antwort nennen können, aber es ist das Einzige, was ich mir vorstellen kann, um den Zugang zu einer Entität in einem Aggregat wirklich einzuschränken.

[EDIT]: Auch zu erwähnen vergessen ... in der Nähe für die Dokumentation ist, dass es ein @internal für phpdoc ist: http://www.phpdoc.org/docs/latest/for-users/tags/internal.html

ich, dass es Zweifel wird der Code-Vervollständigung des IDE ändern, jedoch. Sie könnten jedoch wahrscheinlich eine öffentliche Funktion/Eigenschaft erstellen, sie jedoch mit "phpdoc" als "@access private" kennzeichnen, um zu verhindern, dass sie in Code-Vervollständigung übergeht.

+0

@internal könnte die Lösung sein, aber bis heute wird es immer noch nicht unterstützt! – Benjamin