Jak dla mnie trochę popsuta hermetyzacja.
Metody doContent() i protect() klasy API odpowiadają dość różnym zadaniom. Nie powinno się projektować klasy, która robi zbyt wiele rzeczy na raz. Generalnie 1 rzecz = 1 klasa. Zbyt obszerna klasa przestaje mieć coś wspólnego z obiektówką, a staje się bardziej "modułem", tzn. czymś w rodzaju "przestrzeni nazw" dla strukturalnego zbioru funkcji. Czemu to złe? Chcesz np. coś zmienić w protect(). Być może protect() działa w prozumieniu z jakimś polem prywatnym, powiedzmy $prot. Ale czy $prot nie jest używana gdzieś w doContent()? Tego już nie jesteś pewien. Aby zmodyfikować jedną funkcjonalność muisz analizować kod, który nie ma z nią związku. Nie temu służy idea programzowania obiektowego.
Te Twoje API robi za kontroler, walidator (unieszkodlwiajacy niebezpieczne stringi - ale na co: HTML, SQL?) i za model, np. zarządza użytkownikami tak:
if (isset($_SESSION['cos'])) // zalogowany
A przecież gdy myślimy obiektowo, to aż się prosi by użytkownikowi odpowiadała osobna klasa.
Cytat(matix @ 12.02.2011, 20:25:28 )

W złym. Od tego jest framework - czyli Symfony czy też Zend (wiem, wiem są jeszcze inne równie dobrze, ale nie o to tutaj chodzi).
Po co chcesz wynajdować koło od nowa?
Kolega pisał: "dobrze to jest napisane? chodzi mi o samą logikę aplikacji...". Przecież coś nie może być napisane źle i nielogicznie tylko dlatego, że nie używa framewroka. Co innego, gdy rozważymy cel tego pisania. Mały, duży system. Nauka, praca, hobby? Dojdzie ktoś do zespołu itd.