Parametry metod w interfejsach, uniknięcie wymuszania konkretnych parametrów w metodach Opcje

[Speedy]

hej, próbuję okiełznać częściowo php5 i mam takie pytanie:

Czy da się w jakiś sposób implementować interfejs w danej klasie, ale tak, aby w tej klasie były wymagane tylko konkretne metody, które zawiera interfejs i żeby nie była wymuszana konkretna ilość argumentów dla tych metod? Wiadomo, że interfejsy wymagają utworzenia w klasie konkretnych metod z konkretną ilością parametrów. Ja chciałbym natomiast mieć taki interfejs, który będzie wymagał tylko tego, żeby w klasie znajdowały się metody o konkretnych nazwach, ale w różnych implementacjach będą one miały różną liczbę argumentów. Da się coś takiego zrobić?

Po prostu mam kilka klas, które mają takie same schematy nazewnictwa metod, ale czasami w niektórych metodach jest potrzeba podania większej ilości argumentów niż w innych klasach. Można to oczywiście uwzględnić w interfejsie i dodać parametry do wszystkich metod, ale wtedy te dodane parametry będą w niektórych miejscach w ogóle niewykorzystywane...

[devnul]

func_get_args" title="Zobacz w manualu php" target="_manual, func_num_args" title="Zobacz w manualu php" target="_manual i po problemie, php nie zmusza cie do ustalania konkretnej liczby argumentów, umozliwia tylko ustawienie minimalnej liczby wymaganych argumentów

[Prph]

Ale to zaczyna klucic sie z interfejsami.

Interfejsow uzywasz, zeby wymusic na uzytkowniku uzycie klasy w konkretny, ustalony sposob.

Zalozmy, ze masz klase Konfiguracja:

[PHP] pobierz, plaintext 
<?php
class Konfiguracja
{
  public function load($sNazwaPlikuZKonfiguracja)
  {
	// wczytaj konfiguracje z podanego pliku.
  }
}
?>
[PHP] pobierz, plaintext 

Klase ta dajesz uzytkownikom, bo jest wygodna, szybka i... wygodna
Okazuje sie, ze do pewnej czesci aplikacji nalezy przekazac obiekt tej klasy. Obiekt z kolei tworzony jest nie przez aplikacje, ale przez uzytkownika.

Pan Kazio okazal sie madrzejszy - zrobil tez klase Konfiguracja, ale metoda load przyjmuje obiekt bazy danych, bo konfiguracje Kazio bedzie pobieral z bazy.

W tej chwili pan KAzio przekazuje obiekt konfiguracji do aplikackji, ale z inna metoda load! Jezeli nagle aplikacja zechce wczytac jakis konfig do Konfiguracji, to poda mu plik (bo niby skad ma wiedziec, ze madry Kazio woli baze?).

Dlatego interfejsy okreslaja, jak wyglada klasa i zapewniaja, ze bedzie jej mozna uzyc w sposob prawidlowy.

Troche mnie dziwi pomysl tworzenia 'uniwersalnego' interfejsu dla np. 14 klas, bo sa podobne - utworz 14 interfejsow, albo jak wspomnial kolega - uzywaj func_get_args(), ale nie wiem, czy to najlepszy pomysl.

Pozdrawiam, Adrian.

[Speedy]

Dzięki za odpowiedzi.

Chyba jednak zdecyduję się na zrobienie większej ilości interfejsów dla paru wyjątkowych klas.
Po prostu wydaje mi się, że interfejsy służą także do ujednolicenia budowy kilku klas . Może się mylę...

W każdym razie mogę Wam przedstawić mój konkretny przykład.

Mam sobie taką klasę

[PHP] pobierz, plaintext 
<?php
class info extends abstractModule implements defaultModule {
 
	public function add($params)
	{
	}
 
	public function remove($id)
	{
	}
 
	public function edit($id,$params)
	{
	}
 
	public function getAll($category)
	{
	}
 
	public function getOne($id)
	{
	}
 
}
?>
[PHP] pobierz, plaintext 

I mam jeszcze kilka innych klas o takiej samej budowie, tylko że mają obsługiwać one inne dane. Niektóre z nich posiadają jakieś dodatkowe metody, ale wszystkie z nich muszą posiadać te, co ta klasa napisana powyżej.
Tylko akurat jedna z klas nie potrzebuje żadnego parametru przy metodzie getAll(), więc dla niej i tej podobnych klas zrobię oddzielny interfejs.

[Prph]

O widze MVC

Ktos kiedys mądrze zauważym na naszym forum, ze model nie powinien implementowac czegokolwiek.
Pozniej padlo zdanie, ze model to chyba najtrudniejsza czesc MVC.

Zgadzam sie z pierwszym stwierdzeniem. Dlaczego? Bo tylko ty wiesz jak uzywac modelu, nie aplikacja.

Dwa modele (np GaleriaZdjec i Nowosci) moga byc tak rozne i zawierac tak rozne metody, ze interfejs jest tu absolutnie niepotrzebny. Co innego taka sytuacja:

[PHP] pobierz, plaintext 
<?php
class News_Model_MySQL implements News_Model
{
  public function add($title, $body)
  {
	// wstaw do mysql
  }
}
 
class News_Model_Postgres implements News_Model
{
  public function add($title, $body)
  {
	// wstaw do postgres
  }
}
?>
[PHP] pobierz, plaintext 

Masz dwa takie same modele, ale operujace na roznych zrodlach danych. Wtedy moznaby uzyc interfejsu, ale ja pozostaje przy stwierdzeniu, ze nadal nie ma to sensu

RADA: model nie implementuje niczego.
RADA2: mozesz dla ulatwienia dziedziczcy po jakims prostym modelu otwierajacym Ci dostep do zrodla danych:

[PHP] pobierz, plaintext 
<?php
abstract class MySQL_Model
{
  private $oDB;
 
  public function __construct()
  {
	$this->oDB = new Moja_Baza_Danych;
  }
 
  private function getDB()
  {
	return $this->oDB;
  }
}
 
 
class Moj_Nowy_Model estends MySQL_Model
{
  public function dodajNowosc($tresc, $tytul)
  {
	$this->getDB()->query(/*ble ble*/);
  }
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam, Adrian.

[Speedy]

Odnośnie `RADY2`, to takie coś już zrealizowałem . Dziedziczę sobie jedną klasę w każdej z klas tzw. `modułów` (tak nazwałem klasy, które zawierają metody do operacji na danych w poszczególnych obszarach). Ta dziedziczona klasa, to sterownik bazy danych MySQL. btw. W ogóle chciałem zastosować wzorzec GenericObject, ale chciałbym (niestety) w jak najszybszym czasie wykonać to, co obecnie projektuję, a musiałbym ten wzorzec dokładnie obejrzeć przed zastosowaniem. Jak będę miał kiedyś trochę luzu, to sobie napiszę porządny framework .
Wracając do interfejsów, to wydaje mi się rozsądnym ustawienie jednego interfejsu dla akurat tych klas, które mam, a parametry do metod planuję przesyłać jako tablicę (wtedy będzie we wszystkich metodach taka sama ilość parametrów i będą one kompatybilne z interfejsem). W tych klasach właściwie wszędzie są tylko operacje na danych i w niektórych miejscach tylko takie rzeczy jak przesyłanie/usuwanie plików.
Ten przykład z postgresem i mysql-em jest dobry, bo chyba właśnie o to chodzi w interfejsach . Cóż, może moja filozofia na ich temat nie jest do końca słuszna...

[Prph]

Model nie powiniem implementowac interfejsu. Powiedz,. czy chociaz raz skorzystasz z faktu, ze model ma interfejs?

[Ociu]

hm.. Narzucenie metody, która musi być wykonana ?

[Speedy]

Moim głównym zamierzeniem w tym przypadku jest to, o czym wspomniał przedmówca, tylko sprecyzuję: metoda nie wykonana, lecz zawarta w danej klasie .