Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Dziedziczenie, czy niezależne komponenty?
Forum PHP.pl > Forum > PHP > Object-oriented programming
q3trm
Cześć.


Mam dwie klasy, Pierwsza która pobiera wyniki wykonania odrębnych klasa. Druga klasa Pobierającą wyniki pierwszej klasy i zamieniającą je na dane sesyjne.

Moje pytanie, czy zgodne z zasadami OOP byłoby połączenie, a właściwie wykonanie tych operacji w jednej klasie?


  1.  
  2. class ImageParameter // kąt oraz pliki zdjęć
  3. {
  4. protected $angleImage;
  5. protected $fileImage;
  6.  
  7.  
  8. public function downloandParam(OperationDir $operationDir, AngleImage $angleImage )
  9. {
  10. $this ->fileImage = $operationDir ->getArrayDir();
  11. $this ->angleImage = $angleImage ->getAngleImage();
  12. }
  13.  
  14. public function getAngleImage()
  15. {
  16. return $this ->angleImage;
  17. }
  18. public function getFileImage()
  19. {
  20. return $this ->fileImage;
  21. }
  22. }
  23.  
  24.  
  25. class SessionParameter
  26. {
  27. protected $instance;
  28.  
  29. function takeInstance (ImageParameter $imageParameter)
  30. {
  31. $this ->instance = $imageParameter;
  32. }
  33. function sessionAngleImage()
  34. {
  35. return $_SESSION['angleImage'] = $this ->instance ->getAngleImage();
  36. }
  37. function sessionFileImage()
  38. {
  39. return $_SESSION['fileImage'] = $this ->instance ->getFileImage();
  40. }
  41.  
Evinek
To moje zdanie, a w OOP nie jestem aż tak dobry.

Jedna klasa powinna być od Sesji.
Druga powinna w konstruktorze dostawać wstrzykniętą klasę sesji. Wtedy operacje zapisu powinny być w klasie Image.
Przykład:
  1. class ImageParameter
  2. {
  3. protected $session;
  4.  
  5. public function __construct(Session $session){
  6. $this->session = $session;
  7. }
  8.  
  9. public function saveToSession(){
  10. $this->session->set('angleImage', $this->getAngleImage());
  11. $this->session->set('fileImage', $this->getFileImage());
  12. return $this;
  13. }
  14.  
  15. }


Najlepiej żebyś ktoś mądrzejszy się wypowiedział, a jak mój tok myślenia będzie dobry to będę szczęśliwy. biggrin.gif
q3trm
Mi się podoba snitch.gif
Szymciosek
Możecie mnie przy okazji nakierować co nam daje wstrzykiwanie? Dependency Injection.
Crozin
@q3trm: Mógłbyś proszę przepisać swój pierwotny post - czytam go kolejny raz i nadal nie jestem pewien czy aby na pewno dobrze rozumiem Twoje pytanie. Nie mniej jednak to co zasugerował @Evinek jest najprawdopodobniej poprawnym rozwiązaniem. Jedyne co można by w nim poprawić to zamiast jawnie oczekiwać konkretnej klasy (tutaj: Session) skorzystać z interfejsu (jakiś tam SessionInterface) czy nawet jeszcze lepiej, z ogólnego interfejsu jakiegoś "magazynu" (np. StorageInterface, którego rozwinięciem mógłby być interfejs sesji), bo po co ograniczać swój kod do współpracy z tylko jednym magazynem danych? Oczywiście, jeżeli w Twoim przypadku byłoby to przesadą nie musisz "uciekać" do interfejsów - jednak jest to bardzo dobra praktyka:
  1. interface StorageInterface {
  2. public function get($key);
  3. public function getAll();
  4. public function set($key, $value);
  5. public function has($key);
  6.  
  7. ..
  8. }
  9.  
  10. interface SessionInterface extends StorageInterface {
  11. public function getId();
  12. ...
  13. public function getFlash($key);
  14. public function setFlash($key, $value);
  15. public function hasFlash($key);
  16. }
  17.  
  18. class ImageParameter {
  19. ...
  20.  
  21. public function __construct(StorageInterface $storage) {
  22. ..
  23. }
  24. }


@Szymciosek: Było to już poruszane wielokrotnie. Google: https://www.google.com/search?q=dependency+...me&ie=UTF-8 czy bardziej ogólnie https://www.google.com/search?q=ioc&aq=...600&bih=775 (IoC).
q3trm
Evinek, dał mi rozwiązanie mojego dylematu. Crozin, natomiast Twój kod dał mi sporo do myślenia, aktualnie mój skrypt nie wymaga owego zastosowania, ale na pewno mi się przyda w najbliższej przyszłości.

To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.