Cześć,

Mam FW podobny w miarę strukturą katalogów do Kohany. Jakiś czas temu dodałem w nim przestrzenie nazw. Teraz naszła mnie taka refleksja czy zrobiłem to dobrze. A mianowicie czy nie przedobrzyłem z ich długością.

[PHP] pobierz, plaintext 
namespace Enforcer\System\Libraries;
use \Enforcer\System\Base\Application\Context;
 
abstract class Data implements Context\ImplanterInterface { }
[PHP] pobierz, plaintext 

Przykładowa przestrzeń nazw dla controllera pluginu:

[PHP] pobierz, plaintext 
namespace \Starach\Enforcer\Plugins\Pages\Controllers;
 
class Pages extends \Enforcer\System\Libraries\Controller\ContextImplanter { }
[PHP] pobierz, plaintext 

Tak się zastanawiam czy nie lepiej byłoby skrócić przestrzeń nazw i przedłużyć nazwy klas.
Na przykład:

[PHP] pobierz, plaintext 
namespace \Starach\Enforcer\Plugins\Pages;
 
class ControllersPages {}
class ControllersPageEdit {}
class ControllersPageView {}
class LibrariesPages {}
// edit->
// obecnie
namespace Enforcer\System\Libraries\Client\Language;
class Collection implements \Iterator { }
// zmiana na
namespace Enforcer\System;
class LibrariesClientLanguageCollection implements \Iterator { }
// lub
namespace Enforcer\System\Libraries;
class ClientLanguageCollection implements \Iterator { }
// <-edit
// I tak dalej.
[PHP] pobierz, plaintext 

Co o tym myślicie?

Zwracasz się do ludzie w stylu: "Wojtku synu Piotra z miasta Wrocław w kraju Polska na planecie Ziemia" czy po prostu "Wojtku" ?

@smentek: Co to ma mieć niby do rzeczy?

Co do tematu... jakieś strasznie dziwne masz te nazwy - chociaż ciężko jest to obiektywnie ocenić, bo nie ani za co połowa tego kodu odpowiada, ani jak wygląda całość. Jednak:

1. To "Enforcer" to nazwa Twojego FW? Jeśli tak to dobrze, że jest to pierwszy element nazwy. Jeżeli nie, to zawsze dodawaj sobie nazwę projektu jako początek nazwy.
2. Jakieś człony typu "System" czy "Libraries" wydają mi się niepotrzebne - ale jak już napisałem: nie znam reszty kodu więc nie mogę tego jednoznacznie określić. Być może ich użycie jest w Twoim przypadku jak najbardziej poprawne
3. Każdy plugin jednak dobrze by było jakby miał osobną przestrzeń na swoje kontrolery, swoje widoki swoje coś tam i jeszcze coś innego

@smentek: Co prawda nie ma to tutaj zastosowania, ale analogia jest jak najbardziej trafna.

@Crozin: Całość jest strukturą bardzo bardzo podobną do Kohany.


etc.

Zastanawiam się czy nie przedobrzyłem przy podziale na przestrzenie nazw. Na dobrą sprawę zastanawia mnie teraz tylko poniższa sprawa.

[PHP] pobierz, plaintext 
namespace Enforcer\System\Libraries\Client\Language;
class Collection implements \Iterator { }
// W chwili obecnej jest tak jak wyżej
// Czy nie powinienem stosować jednak poniższego zapisu? Zacząłem odnosić wrażenie że poniższy podział na segmenty przestrzeni nazw jest wystarczający.
namespace Enforcer\System\Libraries;
class ClientLanguageCollection implements \Iterator { }
[PHP] pobierz, plaintext 

Jak sądzisz?

Innymi słowy chciałbym znaleźć jakąś regułę dotyczącą granic dzielenia klas na paczki.

Podał po prostu "ludzkie wytłumaczenie" idei przestrzeni nazw - dlatego zapytałem co to ma do rzeczy.

Bardzo ciężko odpowiedzieć nie znając całości (większego fragmentu) kodu. Jakiś sztywnych reguł nie ma. Jeżeli w Enforcer\System\Libraries miałbyś mieć 5 klas to ok, jeżeli 250 to już niezbyt to dobre będzie. Innymi słowy: to zależy (piszę to chyba 3. raz dziś :]).

Powinieneś się raczej kierować jakąś tam logiką przy tym podziale. W każdej przestrzeni powinny znaleźć się tylko powiązane tematycznie klasy/interfejsy. Jeżeli miałbyś skończyć na 10 przestrzeniach po dwie klasy mógłbyś pomyśleć o jakiejś bardziej ogólnej nazwie i zebrać to w jedną paczkę - oczywiście tylko w przypadku, gdyby wszystko dotyczyło tego samego "tematu".

No fakt od tego jest niby UML, ale FW w założeniu ma być bardzo modularny żeby poszczególne elementy można było rozwijać autonomicznie. Ciężko jest zaplanować każdą funkcjonalność - a co za tym idzie klasy - we wtyczce która z założenia ma być rozwijana przez choćby nawet tylko rok. Dlatego chyba będę stosował podejście nadmiarowe. Czyli muszę się jakoś pogodzić z nadwyżką segmentów w przestrzeniach nazw.

To nie jest kwestia przestrzeni nazw, tylko budowy Twojego frameworka. Teraz masz:

[PHP] pobierz, plaintext 
namespace \Starach\Enforcer\Plugins\Pages\Controllers;
 
class Pages{ ... }
[PHP] pobierz, plaintext 

A gdybyś nie używał przestrzeni nazw, miałbyś pewnie

[PHP] pobierz, plaintext 
class Starach_Enforcer_Plugins_Pages_Controllers_Pages{ }
[PHP] pobierz, plaintext 

U siebie staram się wszystko rozplanować tak, by drzewo katalogowe miało głębokość dochodzącą do 4 poziomów (gdzie poziom 4 to klasa), w ekstremalnych przypadkach dobijając do 5.

Problem w tym, że nie mam żadnego pomysłu jak je skrócić. Jak mówiłem mój FW bazuje na ideologii Kochany. Jakbyś dodawał do niej przestrzenie nazw to jakbyś to zrobił?

edit>
Teoretycznie można zamienić Enforcer_Plugins na EnfPlugin, ale jest to raczej taki plaster na dupę, a nie jakaś rewolucyjna zmiana. Wszystkie nazwy byłyby krótsze przynajmniej o jeden fragment gdyby nie hierarchiczność, ale może masz jakiś pomysł jak wyciąć jeszcze z jeden fragment.

W ogóle bym się nie brał do pracy na tym czymś.

Nam jest bardzo ciężko określić jak mógłbyś to przerobić, bo... bo nie znamy kodu, który prawdopodobnie trzebaby było przepisać (częściowo). Jedyne co mi się rzuca w oczy to podział na System i Plugins, który IMHO jest niepotrzebny, albo inaczej... mało wygodny. Tutaj mógłbym polecić rozwiązanie na kształt Symfony2 w postaci Bundles (jakoś żadne polskie tłumaczenie mi tutaj nie pasuje). Wtedy potworki typu: \Starach\Enforcer\Plugins\Pages\Controllers\Page. uprościły by się do czegoś w stylu: \Starach\PagesBundle\Controllers\Page. Przeskok z pięciu do trzech segmentów nazwy przestrzeni.

W ten sposób wywaliłeś Crozin część identyfikacyjną pluginu. Fakt faktem że można by to uprościć usuwając ją, ale wtedy klasa ładująca pluginy musiałaby sprawdzać każdą klasę - hmm możne z wyjątkiem ... dobra nie wszystkie. Dzięki zaraz zabiorę się za zmianę nazw na \Starach\Pages\* np. Controllers pozostaje tylko jeszcze kwestia aplikacji i systemu

Enforcer\Application\Controllers
Enforcer\System\Base\Application

Chociaż w sumie nie są one takie straszne i mieszczą się na dobrą sprawę w zasadzie ( max. 4 segmenty )

Dzięki.

Między innymi o to chodziło.
Akurat sposób z Sf2, który zaproponowałem działa na trochę innej zasadzie - nie wyszczególnia się w nim czegoś takiego jak "system" i "pluginy", mimo, iż takowe w sumie istnieją. Rozwiązuje to też problem z Twoim "system".

Przeczytaj sobie na stronach Sf2 - mi się nie chce rozpisywać. Nie mówię, żebyś Copy&Paste robił, ale abyś spojrzał na problem z nieco innej perspektywy.

Wydaje mi się, że za bardzo skupiłeś się tutaj na odwzorowaniu struktury katalogów na namespacy. Nie wydaje mi się aby to miało jakikolwiek sens.
Przecież w własnym FW raczej nie będziesz miał kolizji nazw dlaczego nie zastosować jednego poziomu