Zainteresowałem się ostatnio silnikiem gry ezRPG i w nim mam taką oto klasę:

[PHP] pobierz, plaintext 
<?php
//This file cannot be viewed, it must be included
defined('IN_EZRPG') or exit;
 
/*
  Class: Module_Members
  Shows a list of members.
*/
class Module_Members extends Base_Module
{
    /*
      Function: start
      Displays the members list page.
    */
    public function start()
    {
        //Require login
        requireLogin();
 
        if (isset($_GET['page']))
            $page = (intval($_GET['page']) > 0) ? intval($_GET['page']) : 0;
        else
            $page = 0;
 
        $query = $this->db->execute('SELECT `username`, `level` FROM `<ezrpg>players` ORDER BY `id` ASC LIMIT ?,50', array($page * 50));
        $members = $this->db->fetchAll($query);
 
        $prevpage = (($page - 1) >= 0) ? ($page - 1) : 0;
 
        $this->tpl->assign('nextpage', ++$page);
        $this->tpl->assign('prevpage', $prevpage);
        $this->tpl->assign('members', $members);
        $this->tpl->display('members.tpl');
    }
}
?>
[PHP] pobierz, plaintext 

Czy sprawdzanie takich danych jak $_GET['page'] (czy liczba), powinno znajdować się wewnątrz klasy czy na zewnątrz?
I drugie pytanie przy okazji, czy dane takie jak $_GET nie powinny być przesyłane za pomocą zmiennej do klasy tak jak do zwykłej funkcji:

[PHP] pobierz, plaintext 
$klasa->funkcja($_GET['cos'])
[PHP] pobierz, plaintext 

Nie ma jednoznacznej odpowiedzi na twoje pytania ale postaram Ci się nakreślić temat

Ogólnie przyjęło się robić w ten sposób, że metody klasy jak i sama klasa powinna być zamknięta na zewnątrz. Co oznacza, że nie powinno się używać raczej zmiennych typu $_GET itp w jej wnętrzu. Aby zachować przejrzystość i uniwersalność takiej metody/klasy należy jej żądane parametry przekazać (jeśli boisz się o pamięć - można referencyjnie). Grunt aby dana metoda przyjmowała w argumentach swoich to - co jest jej potrzebne do działania. Przykładowo jeśli masz swoją klase i pracujesz na tablicy $_GET to zmiana na $_POST to kwestia kilku linijek - jeśli dawałbyś to $_GET jako argument metody i dalej pracował na zmiennej lokalnej to zmiana na $_POST była by tylko w jednym miejscu - co więcej można by tam było wrzucać dowolne rzeczy - tak więc mamy uniwersalność

Co do samego sprawdzania zmiennych to są w zasadzie trzy drogi z czego moim zdaniem jedna jest najlepsza:

1. Walidacja danych przed wrzuceniem do metody - zaletą jest to że metoda staje się lżejsza, brak w niej kodu odpowiadającego za walidację stąd też lepiej widać jej samą funkcjonalność. Wadą natomiast jest to, że przed każdym wywołaniem metody musisz walidować dane - można się zapomnieć.

Wyjątkiem od tej wady jest opcja gdy dana metoda jest zawsze wywoływana przez inną, która to zawsze przekazuje już zwalidowane dane. Wtedy oczywiście ta metoda jest najlepsza (po co walidować coś dwa razy?)

2. Walidacja wewnątrz metody i klasy - Na początku metody mamy walidację danych potem kod funkcjonalny samej metody. Zaleta - dane zawsze są walidowane - wada - zaciemnia i powiększa to kod metody.

3. Walidacja wenątrz klasy ale nie metody - W klasie tworzysz dodatkową metodę (prywatną odpowiadającą za walidację danych). W swojej metodzie na początku przekazujesz dane do metody walidującej i dalej wykonujesz kod samej metody. Zaleta jest taka że masz zawsze walidację oraz fakt że dana metoda walidująca może być użyta w wielu miejscach bądź nawet uniwersalna. Dodatkowa zaleta jest taka że masz zawsze walidację w jednym miejscu. Wadą (minimalną) jest to, że w danej metodzie znajduje się "jedna linijka" walidująca dane - lecz nie jest to takie straszne.

Podsumowując - moje propozycje:
ad. 1 - Waliduj wewnątrz klasy - jeśli się uda to zrób dodatkową metodę walidującą aby nie zaciemniać kodu twojej metody
ad. 2 - Przekazuj zmienne w argumentach - uzyszkasz większą skalowalność oraz uniwersalność - plus łatwość zmian parametrów wejściowych (klasa będzie działać zawsze tak samo - Ty wtedy decydujesz na jakich danych w szybki i prosty sposó

1. Powinieneś zawsze stronić od stanu globalnego i w miarę możliwości/zdrowego rozsądku od stanu statycznego. $_GET to zmienna superglobalna - chyba nie trzeba komentować jak zła zatem jest.
2. Sprawdzanie poprawności danych to tak szerokie zagadnienie, obejmujące tak różne struktury danych/konstrukcje, że nie da się przyjąć jakiegoś ogólnego modelu i podsumować go jednym zdaniem. Dla tego konkretnego przypadku powinno to raczej być:

[PHP] pobierz, plaintext 
/**
 * @param int $chunk Numer strony/porcji zwracanych danych
 */
public function start($chunk) {
  if ($chunk < 0) {
    throw new InvalidArgumentException('...');
  }
}
[PHP] pobierz, plaintext 

Tak więc w tym konkretnym przypadku metoda powinna już oczekiwać liczby (niestety język nie pozwala na wygodne zapisanie czegoś takiego*), ale we własnym zakresie może sprawdzić czy aby przypadkiem nie podano nieprawidłowego argumentu.

* od biedy można wewnątrz metody zrzutować sobie zmienna na dany typ: $chunk = (int) $chunk.