"Czy strategia pasuje do paradygmatu obiektowego?". Pytam, dlatego że uważam, że w paradygmacie obiektowym, obiekty powinny dostać coś przez parametr konstruktora. A uważam tak, dlatego że jeśli nie dostają czegoś, to można by zrobić z nich funkcje, po prostu, więc nie byłoby róznicy czy przekażę implementację interfejsu czy callbacka (a nie uważam żeby callbacki się wpisywały w paradygmat obiektowy). A po drugie dlatego, że wtedy nie byłoby znaczenia czy użyję tych samych instancji jakiejś implementacji czy różnych. Nie wydaje mi się że te dwie ostatnie cechy pasują do paradygmatu, a jednocześnie widzę że strategie je mają stąd pytanie - "Czy strategia pasuje do paradygmatu obiektowego?"
No dobra, ale czy jeśli mam aplikację, w której mam tysiąc klas, które dostały coś przez parametr konstruktora, i jedną, która nie, to to już nie będzie kod obiektowy? Czy może jeśli język pozwala na tworzenie bezparametrowych konstruktorów, nie jest językiem obiektowym?
Ja bym wtedy powiedział, że 99% aplikacji jest napisanej obiektowo, i ma jedną proceduralną klasę.
Podobnie jak masz 99% coverage'a, to nikt nie powie że kod niej est przetestowany, ale nie można też powiedzieć żę jest w pełni przetestowany.
Jeśliby poprawić tą klasę na obiektową, to wtedy powiedziałbym że aplikacja cała jest w pełni obiektowa. Podobnie, gdybym odpalił mutaion testing engine, i on by zapił 100% mutatnów, to powiedziałbym żę aplikacja jest w pełni przetestowana.
Co do języka: Już bardzo dawno przesatłem używać takich określeń jak "obiektowy język", "funkcyjny język", nie mają takie określenia sensu dla mnie. Można pisać obiektowo w nieobiektowym języku. Takie określenia dla mnie straciły już sens. Metafora, nawet jak znajdę wegetariańskie danie, to łatwo zrobić je niewegetariańskim, tak samo łatwo jak napisać nieobiektowy kod w rzekomo obiektowym języku.
Ja teraz nie posługuję się w ogóle określeniami "obiektowy język", i mówię tylko "obiektowy kod" albo "nie obiektowy kod". Nie ma języka który by Cię zmusił żebyś uniezależnił dane od implementacji, zawsze jak się uprzesz, to złamiesz gdzieś paradygmat.
Czyli aplikacja posiadająca obiekty, ale która cześć logiki ma np w funkcjach statycznych jest obiektowa?
No to w takim razie żadna aplikacja nie jest obiektowa.
Niektóre są. Mogę sobie łatwo wyobrazić aplikacje która nie ma absolutnie żądnej logiki w funkcjach statycznych, i spełniająca pozostałe założenia.
Tylko własnie nie wiem co tutaj jest kluczem.
@somekind: Chodzi o to że strategia nie jest widoczna poza obiektem?
Obiekty są 3:
- Jeden główny, który chce coś zrobić, i wie jakim algorytmem chce to zrobić. On tworzy/wybiera obiekt konkretnej implementacji algorytmu, i przekazuje go dalej.
- Drugi, który trzyma referencję do konkretnej implementacji algorytmu, dostaje ją np. w konstruktorze i używa w swoim flow.
- No i wreszcie obiektami są konkretne implementacje algorytmu.
Między nimi gdzieś tam poniewiera się interfejs, aby to wszystko połączyć, bo taką mamy składnię.
Tak więc, strategia nie jest widoczna poza obiektem 1, a używa jej obiekt 2. W Twoim kodzie brakuje któregoś z nich.
Czyli możnaby ją zrefaktorować do innego rozwiązania, np if
ów? Albo innego dowolnego? I klienci tej klasy 1. by nie wiedzieli? Bo rozumiem że klasy 2.
nikt nie używa bezpośrednio, a jedynie za pośrednictwej klasy 1.
?