Zacznę może od tego że nie rozumiem w ogóle idei ubierania w obiekty prostych kodów w języku tak elastycznym jak PHP, ale skoro tyle osób widzi w tym sens, to pewnie coś w tym jest i chciałbym wiedzieć co. Najlepszym chyba sposobem jest zaczęcie programowania obiektowego. Przeczytałem arty na gajdaw.pl, a poniżej pierwsze wypociny:

[PHP] pobierz, plaintext 
<?php
class session {
 
	public static $tcookie='session_class_timestamp';
	public static $tsession='session_class_timestamp';
	public static $dsession='session_class.details';
	public static $visited='session_class.visited';
	public static $lifetime=600;
 
 
	protected function first(){
	}
 
 
	protected function next(){
	}
 
 
	protected function failed(){
	session_destroy();
	die();
	}
 
 
	private function simple(){
 
		$hash=md5(@$_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]);	
		if(isset($_SESSION[self::$dsession])){
 
			if($_SESSION[self::$dsession]==$hash) return true; else return false;
 
		} else {
			$_SESSION[self::$dsession]=$hash;
			return true;
		}
	}
 
 
	private function advanced(){
 
		if(isset($_SESSION[self::$tsession]))
			if(!isset($_COOKIE[self::$tcookie]) || $_SESSION[self::$tsession]!==$_COOKIE[self::$tcookie])
				return false;
 
		$timestamp=md5(microtime());		
		$_SESSION[self::$tsession]=$timestamp;
		setcookie(self::$tcookie,$timestamp,time()+self::$lifetime);
		return true;
	}
 
 
	public static function start($advanced=false){
	ini_set('session.use_only_cookies','1');
	ini_set('session.cookie_lifetime',self::$lifetime);
	ini_set('session.gc_maxlifetime',self::$lifetime);
	session_start();
	$advanced_result=$advanced?self::advanced():true;
	if(!self::simple() || !$advanced_result)
		{
		self::failed();
		return false;
		} 
		else
		{
		if(!isset($_SESSION[self::$visited])) {self::first();$_SESSION[self::$visited]='1';} else self::next();
		return true;
		}
	}	
 
}
?>
[PHP] pobierz, plaintext 

No i oczywiście pojawiły się problemy. Miało to działać tak (jeżeli mój tok myślenia odbiega od OOP to proszę o wyjaśnienia):
- klasa miała być uniwersalna żeby łatwo mogła współpracować z klasą odpowiedzialną na przykład za obsługę użytkowników
- w przypadku wywołania przez session::start(true) dodatkowym zabezpieczeniem miało być sprawdzanie czasu wykonania ostatniego wyświetlenia strony przez użytkownika.
- metody next i first miały być przeznaczone do przesłaniania aby dało się na przykład łatwo wpleść licznik odwiedzin (z tego co czytałem wasze posty klasa powinna odpowiadać za jakąś warstwę aplikacji i stąd ten pomysł), failed też miała być do ewentualnego przesłonięcia, ponieważ nie do końca wiem jak się ma private do przesłonięcia są zdefiniowane jako protected.

Przy wywołaniu statycznym jednak przesłanianie metod nie działa, a jak na moją logikę tworzenie obiektu w tym przypadku jest marnotrastwem zasobów i rozwiązaniem mniej estetycznym.

Jak można to ominąć i czy jeśli chodzi o logikę OOP to popełniam jakieś błąd??

Ze statycznymi rzeczami taki problem jest, ma być to zmienione, na późne wiązanie, ale chwilowo można o tym pomarzyć.
Co do wydajności, to bym nie był takim pesymistą.
Nie można też mówić o OOP kiedy mamy w użyciu jedną klasę.
Dodawaj też phpDoc to ułatwia czytanie co dana klasa ma robić, jak jej użycie w dobrym środowisku programistycznym.

No cóż, nie bardzo wiem co dalej z tym zrobić (nie jest mi ta klasa do niczego potrzebna, bardziej chodzi o sens OOP)
1. Przerobić klasę, aby wymuszała tworzenie obiektu i przysłaniać metody
2. Przerobić metody na pola logiczne first oraz failed i pozostawić możliwość ich kontroli z poziomu innej klasy,
3. Umieścić mechanizm odpowiadający za first i next w klasie odpowiadającej za usera, jednak pozostanie problem metody failed, który należy kontrolować wyjątkami (to by w sumie dało możliwość rozbudowy klasy), lub przez wartość zwracaną przez session::start()
4. Przy pomocy try szukać czy user zdefiniował funkcę o ustalonej nazwie (to chyba nie ma nic wpólnego z OOP )
5. Zdefiniować te metody jako abstract, choć uniemożliwi to szybkie wykorzystanie klasy osobom które nie znają się na sesjach bądź OOP.
6. Przejść całkowicie na obsługę wyjątków, bądź jakiś skomplikowany sytem zwracanych wartości np. na flagi błędów w jakiejś reprezentacji tablicowej bądź binarnej, czy też pola pokazujące wszystkie możliwe stany.

Czy punkt 1 jest tutaj najlepszym rozwiązaniem?

Na początek połącz to z handlerem sesji session_set_save_handler(); Wtedy ze swojej sesji korzystasz tak jak ze zwykłej natywnej sesji z PHP....

Nie widzę potrzeby zmiany sposobu zapisu sesji, bo ten oryginalny jak na moje potrzeby jest zupełnie wystarczający, jeśli się nie zostawi furtki do pliku sesji. A bardziej chodzi mi o OOP. Gdyby ktoś z Was miał jakiegoś świeżego programistę do dyspozycji i miałby wam napisać prostą klasę do obsługi sesji pod jakiś portal (na razie samo bezpieczeństwo sesji powiedzmy że do tego jeszcze dorzucenie sprawdzenia referer z nagłówka z ostatnio odwiedzonym URI w sesji), to jak ta klasa miałaby być obsługiwana później przez doświadczonego programistę o ile Wy w ogóle takie rzeczy wrzucacie w klasy.

Edit: to po prostu moja pierwsze w życiu podejście do OOP po ponad 15 latach przyzwyczajania się do myślenia proceduralnego czy tam strukturalnego i tak naprawdę póki co sens w OOP w PHP widzę w rozwiązaniach takich jak CURL, gdzie obiekt ma naprawdę olbrzymią ilość pól i sterowniki baz danych gdzie definiuje się uniwersalny interfejs a pod niego pisze się klasy do obsługi Postgresa albo MySQL. Natomiast w dziale gotowe rozwiązania widzę np klasę bodaj kolegi cysiaczka(jemu braku wiedzy napewno zarzucić nie mogę) PeselValidator, której w życiu nie napisałbym obiektowo bo nie widzę w tym sensu. Ponieważ prawda jest taka że wszystko da się napisać obiektowo i proceduralnie, chciałem napisać z Waszą podpowiedzią napisać kilka klas i połączyć je w jakąkolwiek aplikację. Tyle że jak napiszę to żeby napisać, to najwyżej wyjdzie z tego proceduralne ubrane w słowa kluczowe z obiektowego i w ten sposób napewno nie poznam uroków programowania obiektowego.

@netmare
Zaczynasz od czegoś, od czego nie powinieneś, bo klasa do obsługi sesji jest specyficzna, tak jak napisał ayeo lepiej od razu użyć session_set_save_handler(), bo to przysłania sposób działania, a nadal możesz użyć klasy do obsługi.
Jakbym zaczął jednak od innego problemu, bo na początek zazwyczaj lepiej zacząć od prostych rzeczy.

Dzięki w ogóle za zaintersowanie.

Nie łapę kwestii session handlerów, ani po co ich w ogóle użyć i dlaczego gdybym już chciał ich użyć to powinny być w tej klasie. Ale w takim razie chyba na razię odpuszczę kwestię klasy sesji.

Możesz podpowiedzieć mi co mogę spróbować napisać żeby to miało coś więcej wpólnego z OOP niż sterownik do bazy danych ?

Używasz ich, bo wtedy w projekcie możesz korzystać z tablicy $_SESSION a ona wykorzysta Twój mechanizm. Czyli takie niewidoczne korzystanie. Dlaczego używać obiektu, a nie po prostu funkcji, skoro i tak nie widać klasy, bo obiekt zamyka to wszystko w całość, czyli jak szukasz to w jednym miejscu. Do tego możesz tworzyć kreator różnych sesji, i w zależności od projektu przekazywać obiekt o zadanym interfejsie do kreatora, a on już podczepi pod hendler.

Teraz nic mi nie przychodzi do głowy, oprócz rzeczy z pracy :|

EDIT nie odwróciłem znaczników cytatu

Teraz to mi rozjaśniłeś
Generalnie sama funkcja session_set_save_handler(); jest mi znana tyle, że nie zrozumiałem co ayeo miał na myśli.

Popróbuję może trochę rozwinąć tą klasę i dołożyć do niej jakąś inną i może kiedyś coś z tego wyniknie
Jeszcze jedno wpadło mi w sumie do głowy... tak w sumie na zapas... czy dobrze mi się wydaje, że klasa odpowiadająca za sejsę czy też taka odpowiadająca za użytkownika nie powinny być obsługiwane metodami statycznymi, ale powinny działać na obiekcie i do tego nie zezwalać na więcej niż jedną instancję (o ile dobrze zrozumiałem to co czytałem to nazywa się to singleton) ?