Używanie klas zamiast funkcji globalnych w functions.php

W wielu motywach, które widziałem (w tym TwentyEleven) oraz w przykładach, które znalazłem w Internecie, podczas tworzenia functions.phppliku dla motywu cała funkcjonalność jest zadeklarowana w zasięgu globalnym. Aby to wyjaśnić, tak wygląda typowy plik funkcji:

function my_theme_do_foo() { // ... }

function my_theme_do_bar() { // ... }

add_action( 'foo_hook', 'my_theme_do_foo' );

Wydaje mi się, że rzeczy mogłyby być „otoczone” trochę lepiej, gdyby użyto klasy:

class MyTheme {
    function do_foo() { // ... }
    function do_bar() { // ... }
}

$my_theme = new MyTheme();

add_action( 'foo_hook', array( &$my_theme, 'do_foo' ) );

Zalety drugiego podejścia (w moich skromnych oczach):

• Krótsze nazwy funkcji
• Dostęp do zmiennych instancji (największa zaleta IMO)
• Brak funkcji globalnych

Wady:

• Nazwa klasy nadal może powodować konflikty
• Nie tak jasne jest „dostosowywanie” za pomocą motywu potomnego (musiałby rozszerzyć klasę nadrzędną)
• Większość motywów nie zrobiła tego w ten sposób, więc przełamiesz ten trend

Prawdopodobnie pomijam niektóre rzeczy, ale zastanawiam się, dlaczego nie zastosować podejścia OOP? W ogóle wydaje mi się to „czystsze”. Być może się mylę?

Jestem dość nowy w tworzeniu motywów WordPress, więc wybacz mi, jeśli jest to powszechna wiedza w społeczności WP :). Próbuję tylko dowiedzieć się, dlaczego rzeczy są takie, jakie są.

Używanie klasy do enkapsulacji jest bardzo popularnym podejściem wielu programistów do wtyczek. Robię to i uważam, że jest czystszy. Ale dla wtyczek. Tematy są z natury bardziej proceduralne.

Nie robimy tego dla domyślnych motywów WordPress, ponieważ podnosi barierę wejścia. Funkcje są dość proste. Usuwanie akcji powiązanych z klasami może być trudne (i potencjalnie może powodować błędy w określonych okolicznościach).

Można również podłączyć szereg funkcji w domyślnych motywach. Rozszerzenie klasy i zastąpienie metod jest o wiele bardziej skomplikowane niż samo zdefiniowanie funkcji. I chociaż dwa różne aspekty kodu mogą zastępować różne funkcje, nie można dynamicznie rozszerzać klas. Jak wskazałeś, potrzeba rozszerzenia klasy nadrzędnej jest zdecydowanie wadą.

Zastanawiałem się nad tym, czy opcje motywu Twenty Eleven stanowią kod klasy, ale nigdy się do tego nie zabrałem. Ten rodzaj osobnej, podobnej do wtyczki funkcjonalności wydaje się dobrym kandydatem do enkapsulacji.