Oop zapouzdření collection – PHP – Fórum – Programujte.com

Ahoj mám pár dotazů k oop

1) tím že deklaruji vlastnost ve třídě s private ,tak jsem tím vytvořil zapouzdření???

2) měl jsem zato že zapouzdření je k tomu aby se nikdo z venku nedozvěděl co mám uvnitř třídy a pak jsem

zjistil že pokud přistupuji k vlastnostem třídy přes setry nebo getry,  tak ty vlastnosti beze studu změním .

Není to tak trochu porušení základního principu zapouzdření.

Prý je to dobré ve větších projektech , kde se později dá vše potřebné snadno změnit bez větší námahy.

3) Pro otázku č.2 je prý řešením COLLECTION . Bohužel jsem nikde nevygooglil moc článků

které by mi kolekce nějak blíže vysvětlily. Takto chápu kolekce já. V kolekcích se deklaruje nekolik instanci s různými parametry, já si vyberu jen jednu instanci kterou zrovna potřebuji poté deklaruji vlastnost  jako pole a do něj se

vloží použitá instance do indexu, při dalším použití nějaké instance se zjistí pomocí klíče jestli už náhodou daná instance nebyla použita a popřípadě to vyhodí chybu nebo něco jiného. Nevím jestli to chápu dobře

pokud jste někdo znalý mohli byste mi to trochu víc osvětlit.

4) konstruktor se inicializuje hned při dotazu z instance objektu , to znamená že při zaslání dotazu do třídy se ihned nastaví třídní vlastnosti podle zaslaných parametrů od objektu, moje otázka je jestli jsem to pochopil správně

5) měl bych přes konstruktor nastavovat jen vlastnosti public nebo je nějaké pravidlo pro nastavování hodnot vlastností.

6) kdy mám používat konstruktor a kdy ne. Někdo tvrdí že bych měl konstruktor použít vždy a v knize php6

programujeme profesionálně zase píší že bych ho měl požít jen když je to třeba.

// otázka č1
<?php
    class Demo{
    private $_name; // je tato vlastnost zapouzdřená?
    }   
   
?>

// otazka č 2
    class Demo{
    private $_name;  // zapoudřená vlastnost
    
       public function getName(){  // nastavení přístupu
    return $this->_name;
    }
    
    public function sayHello(){    // metoda pro vypsání 
    print "ahoj ".$this->getName()."!";
    }


      public function setName($name){   // metoda pro nastaveni hodnoty 
      if(!is_string($name) or strlen($name) == 0){
      echo "spatný parametr pro nastaveni";
      }
      $this->_name = $name;
    }
    
       }
// zpráva od objektu
     
 
 $objDemo = new Demo();  // instance
 $objDemo->setName ('Karle'); // pozadavek pro nasteveni hodnoty
 $objDemo->sayHello(); // vypsani hodnoty
   

// otazka č5. je lepsi nastavovat pres konstruktor jen public vlastnosti
class Log
{
    public $soubor;

    function __construct($soubor) 
    {
        $this->soubor = $soubor;
    }

    function loguj() { ... }
}

$log = new Log("hodnota");
...
...
...

Předem děkuji za rady

#1 xmlatickax

1. Ano
2. Je to porušení principu zapouzdření, ale je to v módě
3. Kolekce slouží ke sdružení objektů. V PHP se jako kolekce používá array
4. Konstruktor je první metoda, která je automaticky volána při vytvoření instance
5. Konstruktorem se nastavují hlavně private vlastnosti
6. Jsou případy, kdy konstruktor není potřebný, ale je jich málo

*

1. Je zapouzdřená až moc. Je nedostupná. Nepoužívej podtržítka
2. Místo sayHello() se obvykle používá magická metoda __toString()

#2 Kit
Děkuji za odpovědi na mé otázky. pomohlo mi to.

2. settery vesmes poruseni zapouzdreni nejsou - setter muze porad hlidat co se do objektu nastavuje a tim udrzet integritu objektu (narozdil od primeho pristupu k atributu)

#4 KIIV

To znamená že se nemusím bát používání setterů pokud  vše řádně očistím ?? .

Ano, princip zapouzdreni je v tomto smeru hlavne o tom, ze se objekt nemuze dostat do "zakazaneho" stavu (tj. stavu nekonzistence) nastavenim nejakeho atributu. Pokud to v setteru ohlidas, tak s tim neni problem. Pokud bys pristupoval primo, tak bys to musel hlidat vne objektu - coz samozrejme ani nemusis vedet, nebo to muzes zapomenout a tak...

#5 xmlatickax
To znamená, že ošetření vstupních dat budeš dělat uvnitř setteru. Pak teprve bude sloužit tomu správnému účelu. Objekt by neměl mít žádné veřejné atributy.

#7 Kit
Moc nerozumím tomu že by objekt neměl mít veřejné atributy?, můžeš mi prosím tě napsat nějaký špátný příklad a k němu správné řešení. Děkuji.

#8 xmlatickax
Však jsi tady takový příklad napsal 

<?php
class Log {
    public $soubor;
    public $data;
}

Správně bys měl udělat všechny atributy privátní 

<?php
class Log {
    private $soubor;
    private $data;
}

a k tomu dopsat konstruktory a metody, které s těmi atributy a dalšími daty budou pracovat. To znamená, že vůbec nemusíš psát gettery a settery, pokud je skutečně z nějakého vážného důvodu nepotřebuješ.

#9 Kit
Dík už mi to došlo , tedy potom vše budu ošetřovat v konstruktoru a tím se celkem pohodlně vyhnu setterům, ?

#10 xmlatickax
Když data předáš v konstruktoru, settery už psát nemusíš. Podobně když si výstup dat uděláš v metodě __toString(), tak nemusíš psát ani gettery. Třída pak vypadá tak, že v ní jsou privátní atributy, konstruktor, metoda __toString() a případně pár metod, které ty atributy mohou modifikovat nebo prezentovat. Neměl bys v nich používat příkazy echo a podobně.

Při modifikaci se dělá validace, sanitizace a další úpravy, které jsou potřebné před uložením. Pokud jsou vstupní data neplatná, měla by taková metoda vyhodit výjimku.

Při prezentaci naopak z atributů poskládáš takovou datovou strukturu, která je požadována. Například string, seznam, slovník nebo jen číslo. Pokud je požadováno více druhů výstupů z jednoho objektu, napíšeš více metod. Pokud jenom string, můžeš použít metodu __toString().

#11 Kit
Opět dík za rady, to je dost poučné.

ak triedu chapes ako objekt (v OOP je to dost bezne) tak by absolutne nemala obsahovat accessory ako take (samozrejme su vynimky ako napr POJO a podobne ktore ale sluzia vyssim cielom) ... objekt by mal poskytovat nejaku funkcionalitu nic viac a nic menej ... ak dovolis jeho vlastnost nastavit priamo tak je velka sanca ze robis chybu a mal by si sa nad tym zamysliet - ak na bicykly dovolis nastavit prevod priamo tak sa tym zbavujes pripadnej moznosti znizit pocet prevodov (zvysenie tiez nebude optimalne) a celkovo sa zbavujes zapuzdrenia cize v buducnosti nemozes spravit bicykel ktory by fungoval na inom principe ako prevody (zalezi od implementacie ale v urcitych pripadoch by bolo vhodnejsie pouzit zvysenie/znizenie rychlosti s kontrolou isMaxSpeed() ... v reale tiez nenastavujes prevody len tak ale na zaklade nejakeho ciela) ... pri nastavovani farby si asi moc nepomozes ale mal by si pouzit nejaky enum alebo obmedzit vstup ... pre nastavenie vlastnosti pri inicializacii pouzijes builder pattern ... zapuzdrenie sluzi na to aby si si triedu zabalil a v buducnosti ak sa rozhodnes cokolvek v nej zmenit aby to nemalo dopad na okolie ... tak isto sluzia aj interface

odporucam precitat http://www.javaworld.com/article/2073723/core-java/why-getter-and-setter-methods-are-evil.html

a kniha effective java od Blocha je tiez dobra

sry ze davam priklad z javy ale je to rovnako OOP

ps: setter moze sledovat co sa nastavuje a getter zase co sa vydava ale to je len slaba nahrada za odhalenie vlastnosti objektu a navyse ak vytvoris getter velmi 'smart' tak si spravis viac problemov ako uzitku

ak potrebujes vytvorit zlozity setter ktory by bol smart tak by si mal radsej spravit novy objekt ktory sa o vsetko smart postara a pouzit toto (s dokumentovanim a vsetkym okolo) ... accessory su vazne dost zbytocne