Jak wymusić typ interfejs w tablicy?

Question

Dobry wieczór.

Potrzebuję wymusić typ interfejsu Unit w tablicy.

    public function addUnits(Unit $unit)
    {
        $this->units[] = $unit;
    }

Podczas gdy to normalny sposób, ja chcę wywołać coś w ten deseń:

    public function addUnits(Unit [$unit])
    {
        $this->units[] = $unit;
    }

Oczywiście, takowy kod zwróci błąd.

Próbowałem z czymś takim:

    public function addUnits(array $unit)
    {
        if (!$unit[0] instanceof Unit) {
            throw new \InvalidArgumentException('Objects must be instance of Units interface.');
        }
    }

Ale to sprawdza tylko pierwszy indeks, gdy takowych może być więcej.

Gdyby ktoś potrzebował całego kodu tejże klasy, to:

namespace WarCraft\Unit; 

use WarCraft\Unit\Units\Unit; 

abstract class UnitComposite extends Unit
{
    protected $units = [];

    public function addUnits(array $unit)
    {
        $this->units = $unit;
    }
}

Jakie będzie najlepsze rozwiązanie tego problemu?

---

Rozwiązanie to pętla foreach.

Kod:

        foreach ($unit as $units) {
            if (!$units instanceof Unit) {
                throw new \InvalidArgumentException('Objects must be instance of Units interface.');
            }
        }

 

Answer 1

Skoro to jest tablica obiektow to czemu nie zwykly foreach?

Comments

A ja żym myślał nad while...

        foreach ($unit as $units) {
            if (!$units instanceof Unit) {
                throw new \InvalidArgumentException('Objects must be instance of Units interface.');
            }
        }

Dzięki.

---

Twoje OOP idzie w złą stronę, coraz dziwniejszy kod się robi. ;d

A dlaczego nie klasa UnitCollection jako tablica przechowująca Unit. Dodawanie / kasowanie Unit, odpowiednia dostępność / metody.

Wtedy znika nam ten foreach i niepotrzebny instanceof..

---

Hmmm...

Z tego co mówisz, wychodziłby, że UnitComposite jest mi zbędny.

Zajmę się przeróbką po szkole. Teraz pora na sen.

 Dodawanie / kasowanie Unit, odpowiednia dostępność / metody. 

 Z tego fragmentu nie idzie wywnioskować która klasa ma przechowywać te metody. 

Niee... To nie zagadka na tę porę. Przysiądę, jak już wspominałem, po szkole.

Dobranoc i bardzo dziękuję za ostrzeżenie mnie, że nie tędy droga. :)

---

Efik, coś wykombinowałem.

Wygląda to mniej więcej tak:

Client

//Client

        $this->main_army = new Army([
            new \WarCraft\Unit\Units\Orc()
        ]);

Army

namespace WarCraft\Army;

use WarCraft\Unit\UnitCollection;

class Army extends UnitCollection
{
    protected $unit = [];

    public function getNameUnit() : string
    {
        $nameUnits = '';
        foreach ($this->unit as $unit) {
            $nameUnits .= $unit->getNameUnit();
        }

        return $nameUnits;
    }
}

UnitCollection

namespace WarCraft\Unit;

use WarCraft\Unit\Units\Unit;

class UnitCollection extends Unit
{
    protected $unit = [];

    public function __construct(array $unit)
    {
        $this->unit = $unit;
    }

    protected function getNameUnit() : string
    {
        return $this->getNameUnit();
    }
}

Proszę, daj znać czy tak jest lepiej.

Choć, foreach z instanceof nadal pozostaje.

W innym wypadku możliwym będzie dodanie kodu(Obiektu):

        $this->main_army = new Army([
            new Orc(),
            new Battle()
            // Całkowicie inny obiekt. Oczywiście, zwróci błąd podczas próby
            // wywołania metody potomnych interfejsu Unit.
        ]);

Można też wymusić coś takiego, ale potrzebaby dodać metodę addUnitToArmy(Unit $unit) w klasie UnitCollection. Czyli klasa Client wyglądałaby jakoś tak:

    $this->main_army = new Army();
    $this->main_army->addUnitToArmy(new Orc);
    $this->main_army->addUnitToArmy(new Orc);

Zamiast:

        $this->main_army = new Army([
            new Orc(),
            new Orc()
        ]);

Osobiście wolę wersję z tablicą.

No, chyba, że masz jakąś wskazówkę jak temu zaradzić. Mi w głowie nic nieskomplikowanego nie świta.

Więcej tutaj:

https://github.com/HaKIMus/oopfun/tree/feature

---

https://3v4l.org/2Od6Z

IMHO Coraz bardziej sobie komplikujesz życie. Wszędzie widać powtarzalność kodu.
PHP na razie nie jest przystosowany do takich rozwiązań chyba, że wejdzie rfc z generycznymi.

Dlaczego chcesz wymusić, aby tablica była tylko kolekcją klasy Unit. Na razie to ty wsadzasz tam na siłę coś innego i oczekujesz, że rzuci błędem, nie aplikacja. W aplikacji podejrzewam, że Tworzone obiekty będą potrafiły trafić na odpowiednie miejsce  (odpowiednie typy w argumentach metod, fabryki jednostek, vaildatory). Zauważ, że  fabryki* jednostek będą zwracały tablicę z jednostkami i to z tego kontrolera w którym robi się operacje na naszej armii.

Jak widać, nie wymyśliłem też niczego lepszego, Zwykły kontener z ifem sprawdzającym typ.

* wzorzec.

---

Dlaczego chcesz wymusić, aby tablica była tylko kolekcją klasy Unit. Na razie to ty wsadzasz tam na siłę coś innego i oczekujesz, że rzuci błędem, nie aplikacja. 

W sumie to masz racje. Jeżeli ktoś będzie widział powód aby wcisnąć tam budynek, to czemu by nie pozwolić mu tego zrobić? (O ile spełni wymagania metod interfejsu dla poprawnego działania).

class UnitContainer extends ArrayObject{...}

To o to chodziło w:

A dlaczego nie klasa UnitCollection jako tablica przechowująca Unit. 

Przerabiając Twój kod pod moje oczekiwania byłoby to niemal niemożliwe / zostałoby na tym samym. W moim przypadku nie występuje setter w postaci __construct, jedynie sztywnie ustalony getter.

Lub, można dodać setter, lecz jako abstrakcyjna, gdyż nie każda klasa implementująca będzie chciała mieć takie samo miano, gdy pozostawimy go pustym.

//Orc
    public function setNameUnit($name = 'Orc')
    {
        $this->nameUnit = $name;
    }

Gdybym chciał to dać w __construct() odpada default'owa opcja.

   new  Unit('Orc',1),
   new  Unit('Orc',2),
   new  Unit('Orc',3),
   new  Unit('Orc',4),
   new  Unit('Foortman'',5)

Jest dość męczące.

IMO to opcja z ArrayObject jest mało korzystna.

Wszędzie widać powtarzalność kodu. 

Wyeliminowane. (O ile to o to chodziło). W ogóle nie było wyeliminowane... Jeszcze gorzej!

abstract class UnitCollection extends UnitFactory
{
    protected $units = [];

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

class Army extends UnitCollection
{
    protected $units = [];

    public function getNameUnit() : string
    {
        $nameUnits = '';
        foreach ($this->units as $unit) {
            $nameUnits .= $unit->getNameUnit();
        }

        return $nameUnits;
    }
}

Jeżeli mielibyśmy odwoływać się bezpośrednio do potomnych interfejsu Unit to odbywałoby się to w bardzo podobny sposób.

Co do:

abstract class UnitCollection extends UnitFactory
{
    protected $units = [];

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

class Army extends UnitCollection
{
    protected $units = [];
    [...]
}

Po klasie UnitCollection może dziedziczyć więcej klas, gdy zajdzie taka potrzeba. Gdybym dodał do Army __construct(), a w przyszłości któryś z obiektów potrzebowałby składowej unit nie miałoby większego sensu rozszerzanie o Army - jeżeli taka klasa nie potrzebuje metod Army.

---

Baran ze mnie.

Miałeś rację.

Podczas próby dodania Battle zobaczyłem jak bardzo potrzebuję czegoś w stylu UnitContainer i jak zbędny jest UnitCollection.

Ehh... A było się od razu posłuchać to nie... Wstawiłem pół projektu, nieprzemyślane wizje i zadowolony, że mogę pisać dalej.

Dziękuję i zarazem przepraszam za zaślepki na oczach.

Miłego.