Koncepcja obiektów w projekcie/ocena konstrukcji

Cześć, witam wszystkich serdecznie. Mimo, że forum śledzę już jakiś czas to w końcu coś napiszę ;) Podobno wskazówki od innych i dyskusja nad rozwiązaniem jest jedną z lepszych metoda nauki.

Nie rozdrabniając się - tworzę pierwszy projekt, podczas którego chciałbym poćwiczyć moje oop - jestem na poziomie "świeżaka".

Metoda klasy View odpowiedzialna już za końcowe wyświetlanie szablonu wraz z treścią:

public function display()
{
        $template = new Template();
        
        $metadata = new Metadata($this->data['meta']); 
        
        $meta = $metadata->getMetaContent();
        
        $path  = $template->getCurrentThemePath();
        
        include $path.'.phtml';
}

Klasa Metadata (oczywiście jej fragment dla zobrazowania sytuacji)

class Metadata
{
    private $title;
    private $subtitle;
    private $author;
    private $description;
    private $keywords;
    private $metaContent = array();
    
    public function __construct($meta = array())
    {
        $this->meta = $meta;
        
    }
    
    
    private function getSubtitle()
    {
        if (!array_key_exists('subtitle', $this->meta) || empty($this->meta['subtitle']))
                $this->subtitle = Config::get('subtitle');
        
        return $this->subtitle;
    }
    
    public function getMetaContent()
    {
        $metaContent['title'] = $this->getTitle(); //Na razie brak
        $metaContent['subtitle'] = $this->getSubtitle();
        
        return $metaContent;
    }
    
}

Są to mega wycinki z kodu, jeśli coś będzie nie jasne - opiszę dokładniej, ale moje podstawowe pytanie brzmi - czy o coś takiego mniej więcej chodzi w oop? Czy moja konstrukcja/koncepcja ma sens? Czy na tym polega tworzenie całości z obiektów (czyli dodawanie obiektów składowych tworzonych z klas np. Template czy Metadata by ostatecznie razem stworzyły całość)?

Takich laików jak ja pojawia się pewnie tutaj wielu, ale moi drodzy trochę cierpliwości - każdy z nas na pewnym etapie swojego życia był w czymś nowicjuszem ;)

Pozdrawiam

Generalnie wygląda ok. Zastanawia mnie bardziej klasa Template, której tworzysz instancję, bez parametrów w konstruktorze, następnie pobierasz ścieżkę (a w zasadzie ogólną ścieżkę do templatki) i ją includujesz - tak jakby każdy moduł miał wyświetlać to samo ;) Ale możliwe, że dopiero coś sobie budujesz.

Nie ma jednej słusznej ścieżki robienia czegoś, każdy framework trochę inaczej podchodzi do różnych tematów i ja nie widzę powodów do narzekań, ale to dopiero początek, jeszcze masz szansę coś zepsuć ;)

Tylko to array_key_exists jest niepotrzebne. empty to taka "rozwinięta" wersja isset i nie spowoduje wyświetlenia błędu, gdy klucz, albo nawet cała zmienna nie istnieje. Z manuala: empty() does not generate a warning if the variable does not exist.

Hej @dzek69 - zacznę od końca - z tym array_key_exists właśnie mi wyskoczył błąd, gdy okazało się, że zmienna nie istnieje ;) Tak że dzięki za podpowiedź bo zdecydowanie się przydała ;)

Klasa Template zasadniczo miała tylko służyć do obsługi szablonu głównego aplikacji tj. w zależności od aktualnie wybranego szablonu, oraz trybu Routingu(user/admin) odpowiednia metoda miała zwracać ścieżkę do szablonu, który następnie byłby dołączany jako główny plik widoku, do którego zostaje wczytywana reszta treści, ale Twój post skłonił mnie troszkę do myślenia - skoro aplikacja ma być zbudowana z modułów, to można by wykorzystać tą klasę nie tylko do obsługi głównego szablonu, ale też do szablonów poszczególnych modułów.

10 przykazań.

S – Single-responsiblity principle
O – Open-closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion Principle
Encapsulate what varies.
Favor composition over inheritance.
Program to interfaces, not to implementations.
Strive for loosely coupled design between objects that interact.
Depend upon abstractions. Do not depend upon concrete classes.
BONUS: DRY (Don't repeat yourself)

Kilka błędów. Myślenie ok. Uwagi ogólne

1. Włącz pełne raportowanie błędów na serwerze developerskim - wraz z notice. To bardzo ułatwi ci naukę i tworzenie ładnego kodu.
2. Naucz się korzystania z komentarzy i anotacji: https://www.phpdoc.org/

Uwagi szczegółowe:

1. Sugerowałbym raczej "defaultowe" definiowanie widzialności pól i metod klas jako protected a nie private. To taka uwaga płynąca raczej z doświadczenia - zachowujesz odpowiednią hermetyczność, ale nie ograniczasz się na rozbudowę. To jest szczególnie ważne jeżeli piszesz bibliotekę wielokrotnego użytku, a taki mikro-mikro-framework może za taką uchodzić.
2. Zawsze deklaruj tablice do których kluczy dostęp wykozystujesz. Czyli :

$metaContent = [];
$metaContent['title'] = 'cos';

3. Myślę, że w 2016 roku spokojnie możesz już korzystać z nowej notacji array. Wątpię abyś w normalnych warunkach natrafił na php w wersji poniżej 5.4.

public function display()
{
        $template = new Template();
 
        $metadata = new Metadata($this->data['meta']); 
 
// deklarujesz zmienną której nie  używasz. Do wywalenia.
        $meta = $metadata->getMetaContent();
 
        $path  = $template->getCurrentThemePath();
 
        include $path.'.phtml';
}

5. Generalnie oducz się tej skróconej notacji:

        if (!array_key_exists('subtitle', $this->meta) || empty($this->meta['subtitle']))
                $this->subtitle = Config::get('subtitle');

Nie jest to zapis nieprawidłowy, ale ja zawsze odrzucam takie kwiatki na CodeReview. Pamiętaj, że o jakości kodu nie świadczy jego zwięzłość, w każdym razie nie jako główny czynnik, ale:
a) to czy jego utrzymanie w przyszłości będzie bezbolesne
b) to czy jest czytelny
c) to czy nie jest podatny na błędy
Skrócona notacja nie spełnia żadnego z tych warunków.

Jeszcze kilka drobiazgów, ale to może kiedy indziej.