Chcę stworzyć sobie system CMS, taki który za jakiś czas będę mógł bez problemu rozbudować, i teraz moje pytanie, czy taki podział klas jest dobry rozwiązaniem.

Klasa user.class.php
- dodawanie użytkownika
- kasowanie użytkownika
- edycja użytkownika
- banowanie użytkownika
- podgląd profilu użytkownika
- przypomnienie hasła

Klasa article.class.php
- dodawanie artykułu
- kasowanie artykułu
- edycja artykułu
- podgląd artykułu
- wylistowanie artykułów

Klasa category.class.php
- dodawanie kategorii
- usuwanie kategorii
- edycja kategorii
- podgląd wszystkich kategorii

Klasa news.class.php
- dodawanie newsa
- kasowanie newsa
- edycja newsa
- podgląd newsa
- wylistowanie newsów

Klasa plugin.class.php
- dodanie pluginu
- aktywacja/dezaktywacja pluginu
- edycja pluginu

Klasa db.class.php
W tej klasie będzie wszystko związane, z bazą danych np łącznie z bazą

Klasa validation.class.php
Będzie to klasa odpowiedzialna za walidacja wprowadzonych danych

Klasa filter.class.php
Zastosowanie tej klasy, to filtrowanie wszelkich danych wprowadzanych przez użytkowników

Za wszelkie pomysły, opinie i sugestie z góry dziękuję.

Opiszesz dokładniej co masz na myśli, jak by miało to dokładniej działać ?
Co do reszty to jest chyba ok
Z tym że każda klasa powinna być w stanie zwrócić tak jeden jak i wiele rekordów.

Wgrywasz plugin do folderu plugins, logujesz się do systemu, przechodzisz do zakładki Pluginy, i tam będzie pokazany wgrany plugin, po kliknięciu na niego zostanie on zainstalowany, po instalacji będzie można go aktywować lub odinstalować, w wypadku gdy będzie aktywny, będzie można go usunąć lub wyłączyć. Coś na zasadzie, jak ma wordpress z pluginami

Edycja pluginu, to na tej zasadzie, że wczytuje kod źródłowy pluginu, do pole tekstowego, gdzie będzie można go dostosować do własnych potrzeb, dokładnie edytować jego kod. Choć ten CMS będzie rozwiązaniem dedykowanym, gdzie wszystkie pluginy będą pod klienta, więc możliwość edycji, raczej jest nie potrzebna.

O tym, że każda klasa powinna móc zwrócić jeden lub kilka rekordów to wiem

Takie czynności jak dodanie użytkownika są zbyt skomplikowane dla jednego obiektu, a Ty chcesz po pięć takich wrzucać do jednego. Podstawowa zasada OOP: jeden obiekt, jedno zadanie.

Crozin - to zależy co masz na myśli mówiąc 'dodanie użytkownika' Jeśli chodzi o wsadzenie walidacji pól z formularza + sprawdzenie czy nick jest wolny + insert do bazy to wiadomo jedna metoda w klasie user zajmować się tym nie powinna i można by zrobić jakiś model_registration.
Ale jeśli ExPlOiTowi zależy jedynie na segregacji zapytań na bazie czyli klasa user to zbiór zapytań typu select, insert, update, delete dla tabeli / tabel user to wszystko jest ok. Chyba nie będziesz robić osobnej klasy typu

[PHP] pobierz, plaintext 
class registration{
    public function add($name, $pass){
         mysql_query('insert ...'); //a raczej mysqli czy pdo. Czym się tam bawisz.
    }
}
[PHP] pobierz, plaintext 

Dokładnie to mi chodzi, tak aby nie mieć w przyszłości problemów z rozbudową systemu. Dokładnie coś tego typu:

[PHP] pobierz, plaintext 
class Model_User
{
            private $db;
            public function __construct(database $db)
            {
                $this->db=$db;
 
            }
            //Dodanie nowego użytkownika
            public function addUser($login,$haslo)
            {    
                $this->login=htmlspecialchars($login);
                 $this->haslo=htmlspecialchars($haslo);
                $result=$this->db->query("insert into `users` values('$login','$haslo')");
                if(!$result===false)
                {
                    echo "Wystąpił błąd podczas rejestracji nowego użytkownika!";
                }
                else 
                {
                    echo "Zostałeś zarejestrowany poprawnie.";
                }
 
            }
 
            //Usuwanie użytkownika z bazy
            public function deleteUser($login)
            {
                $this->login=htmlspecialchars($login);
                $result=$this->db->query("delete from users where login='$login'");
                if(!$result===false)
                {
                    echo "Wystąpił błąd podczas usuwania użytkownika!";
                }
                else 
                {
                    echo "Użytkownik o loginie $login został poprawnie usunięty z bazy.";
                }
            }
 
            //Logowanie użytkownika
            public function userLogin($login,$haslo)
             {    
 
                  $this->login=htmlspecialchars($login);
                  $this->haslo=htmlspecialchars($haslo);
                  $result=$this->db->query("select login,haslo from users where login='$this->login' and haslo='$this->haslo'");
 
                  if(mysqli_num_rows($result)==0)
                   {
                       echo "Brak użytkownika o podanym loginie!";
                }
                else
                {
                       $_SESSION['zalogowany']="$this->login";
                       header("Location: test.php");
                 }
 
 
           }
 
 
}
 
?>
[PHP] pobierz, plaintext 

Zastanawia mnie jedno, jak jest dokładnie stworzone zarządzanie użytkownikiem, czy jest to jedna klasa, która wszystko robi, dodaje, kasuje itp, czy dla np dodania i kasowania, tworzone są osobne klasy? Bo szczerze mówiąc, im więcej o OOP czytam, tym bardziej się gubię.

Podziel tą logikę na dodatkowe warstwy: np User (pola name, mail itp), oraz UserDao (metody findBy, Save itp) której to np przekazujesz obiekt User do utrwalania w db.

Nie dawaj echo i zmian lokacji w klasach do tego nie przeznaczonych

[PHP] pobierz, plaintext 
$this->login=htmlspecialchars($login);
$this->haslo=htmlspecialchars($haslo);
[PHP] pobierz, plaintext 

Po co to + brak ochrony przed sql injection
+ po co filtr na hasło ? Hasło daj w md5 z solą czy coś.
+filtrowanie przed xss dawaj przy wyświetlaniu
+
if(!$result===false)
Ten ! powinien tam być?

Dzięki za opinie i sugestie, a co do !, jakoś tak mi się tam wkradł

Jeżeli to ma być CMS to nie radzę zaszywać artykułów czy kategorii na stałe w nim. Popracuj nad modułową budową tego.

Powiedzcie mi, czy to jest dobrze napisana klasa:

[PHP] pobierz, plaintext 
<?php
 
class Article{
 
    private $db;
 
    public function __construct(database $db)
    {
        $this->db=$db;
    }
 
    //Dodawanie artykulu
    public function addArticle($title,$message,$author,$category)
    {
        $this->title=htmlspecialchars($title);
        $this->message=htmlspecialchars($message);
        $this->author=htmlspecialchars($author);
        $this->data=date('d-m-Y');
        $this->category=htmlspecialchars($category);
 
 
        $result=$this->db->query("insert into article values('','$this->title','$this->message','$this->author','$this->data','$this->category')");
            if($result===false){
                throw new Exception('Dane nie zostały dodane!');
            }
 
        }
 
    //Kasowanie artykułu   
    public function removeArticle($id)
    {
        $this->id=$id;
 
        if(!is_numeric($id))
        {
            throw new exception("ID nie jest liczbą!");
        }else{
            $result=$this->db->query("delete from article where id='$this->id'");
            if($result===false){
                throw new Exception("Wystąpił bląd podczas kasowania artykułu!");
            }
        }
    }
 
}
 
 
 
?>
[PHP] pobierz, plaintext 

Nie.

Po co pchasz wszystko do $this ?
Nadal nie filtrujesz danych przed sql injection.
Ta klasa nie powinna filtrować danych przed xss + filtrujemy przy wyświetlaniu a nie zapisywaniu .

spawnowi chodzi chyba o addslashes, a htmlspecialchars dajesz tylko przy wyciąganiu danych z bazy, bo po co zaśmiecać bazę danych.

O prepared statements słyszał? Nie? To niech pogooglea.

Poprawiłem kod:

[PHP] pobierz, plaintext 
<?php
 
class Article{
 
    private $db;
 
    public function __construct(database $db)
    {
        $this->db=$db;
    }
 
    //Dodawanie artykułu
    public function add($title,$message,$author,$category)
    {
        $result=$this->db->prepare("insert into article values('',?,?,now(),?,?)");
        $result->bind_param('ssss',$title,$message,$author,$category);
            if(!$result->execute()){
                throw new Exception('Dane nie zostały dodane!');
            }
 
        $result->close();
 
    }
 
    //Kasowanie artykułu   
    public function remove($id)
    {
        if(!is_int($id))
        {  
            throw new exception("ID nie jest liczbą!");
        }else{
            $result=$this->db->prepare("delete from article where id=? limit 1");
            $result->bind_param('i',$id);
 
             if(!$result->execute()){
                throw new Exception("Wystąpił bląd podczas kasowania artykułu!");
            }
        }
        $result->close();
 
    }
 
}
 
 
 
?>
[PHP] pobierz, plaintext 

Crozin słyszałem, o tym

@down Poprawione

Nie addslashes a mysql_escape_string a najlepiej mysql_real_escape_string a już najlepiej prepared statement

Po co escapujesz skoro bindujesz?
+ po co w nazwach metod dajesz Article? O tym że add() dotyczy article informuje już nazwa klasy.
$data != $date + nic z tym nie robisz

//edit
hmm widzę że poszła edycja postu ...

Tak, międzyczasie poprawiłem kod teraz już chyba wszystko jest ok, dzięki za pomoc wszystkim

No to dalej - czemu nazwy raz zaczynasz z dużej a raz z małej litery?
Zdecyduj się (na małe z kamelem) inaczej z czasem zacznie ci to przeszkadzać

+ czemu dajesz db->close() w dodawaniu czy edycji? Wydziel a raczej wywal bo articles się tym zajmować nie powinno.

Ok, poprawiłem wszystko Będę pisał, z małych + camel, czyli np addParam() to tylko przykład oczywiście.

A ja mam trochę inne pytanie co do tego kodu... Jestem zielony jeśli chodzi o obiektówkę ale rzuciły mi się w oczy "echa"... W klasie, metodzie dozwolone jest używanie echo, printf'ów itd.? Sądziłem, że najlepiej przekazywać takie rzeczy poprzez return false; a "na zewnątrz" jakoś to obsługiwać i wyświetlać odpowiednie błędy.

To zależy. Jeśli klasa odpowiada za widok, np. szablon, to oczywiście możesz, a nawet musisz używać echo itp. Ale nie powinno się tego robić w innych częściach logiki.