Usuwanie podstrony/innej treści, Jak to wykonać zgodnie z obiektowością? Opcje

[kiler129]

Witajcie!
Krótko i na temat - postanowiłem z lekka uporządkować kod swojego CMSu i uczynić go bardziej obiektowym. W związku z tym sprawdziłem jaki wpływa na prędkość ma zbudowanie obiektu i wykonanie metody kontra wykonanie metody statycznej, wyniki z lekka mnie zaskoczyły:

[PHP] pobierz, plaintext 
<?php
class test {
 static public function get() { return array(); }
}
 
class test2 {
 public function get() { return array(); }
}
 
$s = microtime(true);
for($i=0; $i<=1000; $i++) {
 $x = new test;
 $y = $x->get();
 unset($x, $y);
}
echo "Object: ".round((microtime(true)-$s), 4)." ms<br/>";
 
$s = microtime(true);
for($i=0; $i<=1000; $i++) {
 $y = test2::get();
 unset($y);
}
echo "Static: ".round((microtime(true)-$s), 4)." ms<br/>";
 
/*
 Object: 0.0036 ms
 Static: 0.0037 ms
*/
?>
[PHP] pobierz, plaintext 

Różnica praktycznie żadna a wg teorii OOP wykonujemy akcję na danym obiekcie więc chyba najsensowniejszym podejściem jest taka organizacja obsługi podstron:

[PHP] pobierz, plaintext 
<?php
 class subpage {
  protected $id = NULL;
  protected $validId = false;   
 
  function __construct($id=NULL) {
   if($id > 0 && textOperations::isInt($id)) { //basic validation
    $this->validId = true;
    $this->id = $id;
   } else {
    $this->validId = false;
   }
  }
 
  public static getList() { }
  public function get() { }
  public function delete() { }
  public function save($arrayWithParams) { }
 }
 
 $page = new subpage(134);
 $x = $page->get();
 $page->delete();
 unset($page);
?>
[PHP] pobierz, plaintext 

Jedna z metod (akurat w tym przykładzie) jest niezależna od id podstrony bo defakto odnosi się nie do jednej a do listy podstron.
Zastanawia mnie natomiast jedna kwestia - czy obiektowo poprawnie będzie rozwiązać to tak:

[PHP] pobierz, plaintext 
<?php
 class subpage {  
  public static getList() { }
  public static function get($id) { }
  public static function delete($id) { }
  public static function save($id, $arrayWithParams) { }
 }
 
 $x = subpage::get(134);
 subpage::delete(134);
?>
[PHP] pobierz, plaintext 

Druga metoda jest wygodniejsza w użyciu, prędkością się nie różni ale nie wiem czy jest to do końca poprawne.
Z góry dzięki za odpowiedź (IMG:style_emoticons/default/smile.gif)

[Zyx]

Niestety nie są sensowne. Znalazłem kolejny błąd. Tworzenie obiektu nie jest częścią wywoływania metody - owszem, trzeba to zrobić, ale to robisz RAZ. Dlaczego zatem w pętli wliczasz do wywoływania metody czas tworzenia obiektu?

Tutaj faktycznie logiczniej jest tworzyć obiekt i ew. zostawiać część metod statycznych.

Nie przekręcaj mojej wypowiedzi. Napisałem jasno, że metody statyczne powinniśmy tworzyć tylko wtedy, gdy wiemy co robimy, co oznacza, że 99% programistów nie powinno używać ich w ogóle. Nie mówię tu o braku umiejętności (chociaż z drugiej strony... (IMG:style_emoticons/default/smile.gif) ), ale o tym, że ich tak naprawdę w ogóle nie potrzebują. Twój problem akurat wybitnie należy do kategorii problemów, gdzie static nie ma żadnego logicznego uzasadnienia.

A jeśli chodzi o klasy z wszystkimi statycznymi metodami to wydaje mi się, że ma to sens w wypadku gdy coś jest często używane w dużej ilości miejsc kodu gdzie przekazywanie uchwytu nie daje korzyści a jest upierdliwe (np. klasa do cache).

To źle Ci się wydaje. Argument "bo jest używane w dużej liczbie miejsc" to brednia do kwadratu, bowiem wtedy musiałbyś w ogóle przestać stosować obiektówkę do większości rzeczy. Co to w ogóle jest "uchwyt do klasy"? Z przykładem z cache też trafiłeś, jak kulą w płot - jest to jeden z fajniejszych tematów do modelowania obiektowego i robiąc tam wszystko statycznie byś go dokumentnie rozwalił.

Ogólnie powiem tak: znasz składnię, wiesz jak działają obiekty, klasy, elementy statyczne. Jednak to, że potrafisz dwie cegły spoić cementem, nie czyni jeszcze z Ciebie architekta. Umiesz używać klas i obiektów, natomiast o programowaniu obiektowym nie masz zielonego pojęcia. Co bym Ci radził na początek, to zostawienie CMS-a i rozpoczęcie od paru ćwiczeń, w trakcie których nie wolno Ci używać słów kluczowych global, static, extends (a i owszem) oraz metod, których nazwy zaczynają się od __, z wyjątkiem __construct() i __destruct(). Ba, powiem nawet więcej: modelując system, powinieneś wręcz zapomnieć o pojęciu klasy, bowiem jak sama nazwa programowanie obiektowe wskazuje, operujemy tu na obiektach i tylko na obiektach, a klasa to jedynie wygodny schemat do tworzenia obiektów o podobnych zadaniach. Co, że restrykcyjne? Nie, to jest istota programowania obiektowego ogołocona ze wszystkich ogłupiaczy. Dopiero gdy się tego nauczysz, będziesz wiedział, że cała reszta to zwykły lukier składniowy i pomoc, która jednak jest pomocą tylko wtedy, gdy znajduje się w doświadczonych rękach.