Próbuje pojąć filozofię programowania obiektowego. Mam z tym problemy i teoria teorią, ale wydaje mi się, że wymaga to też sporo wyczucia. Ale po kolei.

Męczę sie z logowaniem na nie-ważne-jakiej stronie. "Architektura" (słowo oznaczające określony brak porządku w moich pomysłach ) strony to mniej więcej:

index.php - za pomocą switchy wywołuje odpowiednie metody klasy mainframe()
mainframe() - główna klasa, ktorej metody to tak naprawde podfunkcje strony -> logowanie, rejestracja, wyswietlanie profilu itd
uzytkownik() - klasa, ktora zawiera info o loginie, haśle, ziarnie do hasła, id profilu uzytkownika i metody do ustalania ich a takze aktualizowania tych danych w klasie sesja(), a takze komunikuje sie z tab_users();
profil() - klasa, ktora przechowuje duperele o uzytkowniku, ma metody set oraz get, a takze aktualizuje je w sesja() i komunikuje sie z klasą tab_profiles()
sesja() - klasa singleton (na razie jedyny), ktorej zadanie jest bycie warstwa pomiedzy strona a sesja no i zabawa z sesja - ustawia dane z profil() i user() w sesji, sprawdzanie kiedy byla ostatnia akcja (po np. 10 minutach nastepuje wylogowanie) i inne pierdoly

tab_profiles() oraz tab_users() -> klasy bedace warstwa posredniczaca pomiedzy "architektura" a baza mysql. generalnie maja akcje typu zapisz_profil czy pobierz_id_profilu_dla_usera($id) itd. dziedziczą po klasie mysql, ktora zawiera jedynie konstruktor (łączenie się z bazą przez pconnect) oraz destruktor (mysql_close()).

Pytania:
1) jakie uwagi do takiej "konstrukcji"? czy i gdzie znajdą się słabe punkty takiego rozwiązania? robię to na czuja i po swojemu
2) czy i dla ktorych powyzszych klas bawic sie w singleton
3) mam problem, bo mimo, ze tab_profiles() itd dziedzicza polaczenie po mysql(), to sa sytuacje, gdy wywala mi "brak polaczenia z baza", a przy innym miejscu skryptu ładnie to wszystko chodzi

Witam.

"2) czy i dla ktorych powyzszych klas bawic sie w singleton".
Singleton w rzeczy samej powinien dać gwarancję stworzenia wyłącznie jednego obiektu klasy.
Wiem, że wiele osób stosuje go właśnie do połączenia z bazą, aby przypadkiem nie inicjować połączenia
kilka razy, co strat moralnych nie spowoduje, ale spowolni działanie strony.
Inny dobry przykład na singleton to zastosowanie klasy zmiany kursy waluty w sklepach internetowych.
Jeden obiekt powinien to robić, bo w przypadku stworzenia drugiego prędzej czy później
coś się w sklepie rypnie przy aktualizacji cen produktów.

"3) mam problem, bo mimo, ze tab_profiles() itd dziedzicza polaczenie po mysql(), to sa sytuacje, gdy wywala mi "brak polaczenia z baza", a przy innym miejscu skryptu ładnie to wszystko chodzi"

-Może dziedziczą połączenie, ale w niektórych skryptach może nie masz stworzonego obiektu odpowiedzialnego za połączenie z bazą danych, tylko zainkludowaną samą klasę ?
-Może gdzieś rozłączyłeś się z bazą. Jeśli inkludujesz skrypt, który rozłącza się na końcu z bazą danych, to poniżej tego inkludowanego skryptu w programie połączenie z bazą nadal będzie nieaktualne.
-Może winę ponosi destruktor ? Sami twórcy php nie nalegają na ich używanie, bo trudno jednoznacznie stwierdzić kiedy następuje destrukcja.

"1) jakie uwagi do takiej "konstrukcji"? czy i gdzie znajdą się słabe punkty takiego rozwiązania?" robię to na czuja i po swojemu"

Uwagi do konstrukcji ?
"robię to na czuja i po swojemu" - z tego względu same pochwały.
Nie ma web-aplikacji bez słabych punktów.
Jeśli sam kombinujesz to na pewno zauważysz, że coś dało się zrobić lepiej.
Przy następnym projekcie znowu to zauważysz i tak ciągle.
Jeśli skupisz się na gotowych rozwiązaniach typu cms, czy poleganie wyłącznie na frameworkach możesz uspać swoją pomysłowość.
Pewnie wielu ma inne zdanie, ale wolę robić coś sam, co nie będzie idealne, niż zakuwać obsługę najlepszego frameworka.

"Próbuje pojąć filozofię programowania obiektowego. Mam z tym problemy i teoria teorią, ale wydaje mi się, że wymaga to też sporo wyczucia."
Racja - wyczucie to podstawa. Inaczej programowanie obiektowe byłoby tylko programowaniem proceduralnym (z użyciem funkcji nie klas) trochę inaczej wyglądającym.
Programuj obiektowo, jeśli ci to ułatwi sprawę.
PHP to nie Java i mamy wybór czy chemy pisać kod obiektowo, czy proceduralnie.
Zobacz na poniższy przykład.
To jest tak zwany polimorfizm. Oszczędzi ci switch'ów, if'ów itp. Bardzo go lubię:

Pierwszy skrypt - błędne zastosowanie filozofii progr.obiektowego, bo nic nam nie daje:
<?php
class Cat {
function miau()
{
print "miau";
}
}

class Dog {
function wuff()
{
print "hau";
}
}

function printTheRightSound($obj)
{
if ($obj instanceof Cat) { # Przy milionie zwierząt będziesz musiał zrobić milion instrukcji if
$obj->miau();
} else if ($obj instanceof Dog) {
$obj->wuff();
} else {
print "Błąd: Przekazano zły rodzaj obiektu";
}
print "\n";
}

printTheRightSound(new Cat());
printTheRightSound(new Dog());
?>


A tu rozwiązanie powyższego - tak zwany POLIMORFIZM. Dzięki obiektom możesz sobie stworzyć miliony zwierząt. Wystarczy jedna komenda, aby wowołać metodę któregokolwiek.
<?php
class Animal {
function makeSound()
{
print "Błąd: Ta metoda powinna być ponownie zaimplementowana w klasach potomnych";
}
}

class Cat extends Animal {
function makeSound()
{
print "miau";
}
}

class Dog extends Animal {
function makeSound()
{
print "hau";
}
}

function printTheRightSound($obj)
{
if ($obj instanceof Animal) {
$obj->makeSound(); # I zapomnij o switch'ach, if'ach itp
} else {
print "Błąd: Przekazano zły rodzaj obiektu";
}
print "\n";
}

printTheRightSound(new Cat());
printTheRightSound(new Dog());
?>


pozdrawiam

~korkie, proszę korzystać z BBcode

Pozdrawiam!

A szybkie pytanie:

klasa MySQL zostanie singletonem, a czy wtedy klasy potomne tabusers i tabprofiles tez nimi beda? bo jak na razie to nie moge ich zmusic do dzialania (pokazuje mi blad, ze mysql nie ma metody takiej a takiej - ktore faktycznie sa metodami klas jemu potomnych)... i dupa, nie dziala. a moze inny wrzozec?

Witam ponownie.
Poniżej jest klasyczny kod singletona, napisany przez A.Gitmansa - czyli jednego z twórców php:
<?php

class Logger {
static function getInstance()
{
if (self::$instance == NULL) {
self::$instance = new Logger();
}
return self::$instance;
}

private function __construct()
{
}

private function __clone()
{
}

function Log($str)
{
// Zajmie się rejestrowaniem
}

static private $instance = NULL;
}

Logger::getInstance()->Log("Checkpoint");

?>

W tym klasycznym przypadku mamy statyczną funkcję getInstance() oraz publiczną Log($str).
Reszta to funkcje prywatne.
Zmienna, tzn. właściwość $instance też jest prywatna.
Nie można dziedziczyć ani metod (funkcji), ani właściwości (zmiennych) prywatnych.
W związku z tym w klasach dziedziczących z singletona trzeba wszystko co prywatne zdefiniować na nowo.
Tylko w takim przypadku dziedzicząca klasa z singletona powinna mieć inne zadania niż klasa nadrzędna,
gdyż taka jest idea singletona.
Nie zależnie czy programujesz w php, Ruby, Java, czy czymkolwiek innym, singletony się
stosuje po to, aby mieć pewność, że powstanie jeden i tylko jeden obiekt (instancja) danej klasy.

pozdrawiam