🚀 go-pugleaf

On Oct 31, 10:17 pm, Marek Wywiał <onj...@gmail.com> wrote:
> On 31 Paź, 20:54, pakalk <pak...@gmail.com> wrote:
>
> > > To, że nie można polegać na systemie  
> > > wyjątków w PHP - to drugie.
>
> > Czemu nie mozna?
>
> try {
>   jakis kod;} catch(NieMatakiejKlasy $e) {
>
>   print "chcialbym tu dotrzec";
>
> }
>
> póki kod przed w try jest ok, to ok
> gdy dotrze do niestniejącejklasy wyjątku (literówka)
> skończy się fatalem zamiast obsługą
>

To co to ma wspolnego ze zlym systemem wyjatkow?

>
> Metoda statyczna, jest to metodą nie używająca właściwości obiektu w
> którym się znajduje,

Metody statyczne nie sa wlasnoscia obiektow, tylko klas.

> tylko np dodająca 2 wartości przekazane jako argumenty. A do tego
> służą funkcje odpowiednim
> namespace/pakiecie.

Albo w odpowiedniej klasie, ktroa w ten sposob agreguje funkcje.

> To nie jest standard OOP tylko proteza na
> upychanie funkcji w namespace klasy
> w Javie.

Powiedz to autorom UML, bo chyba o tym nie slyszeli, skoro zawarli to
w standardzie.

>
> W pythonie wystarczy umieścić funkcję w pakiecie, nie potrzeba do tego
> wymyślać klasy, w której
> chciałbym mieć tą funkcję.

To po co w pythonie sa metody klasowe i statyczne (inaczej dzialajace
niz w innych jezykach, bo nie w kontekscie klasy)?

>
> Jak już zostało wspomniane moim zdaniem portowanie do języka
> dynamicznego jakim jest PHP wzorców i konstrukcji
> z języka statycznego jest przerostem formy nad treścią, gdyż wiele
> rozwiązań w javie jest stworzonych po to
> by obchodzić jego statyczność i pozwolić wykonać to co w językach
> dynamicznych można na dzień dobry.
>

Twoim zdaniem. A moim zdaniem jest inaczej.

>
>
> > > interfejsów
>
> > Interfejsy sa nieobiektowymi konstrukcjami?
>
> Interfejsy nie są OOP. W przypadku niektórych implementacji używa się
> ich do oznaczania oraz wymuszania spójności interfejsów klas.
>

Ok, musisz to powiedziec autorom UML. Znow. Chociaz po co - oni sie na
obiektowce w ogole nie znaja.

>
> Protected i private też nie należą do OOP tylko do konkretnej
> implementacji OOP.

Ech.. gadasz bez sensu. Enkapsulacja to podstawa programowania
obiektowego.

> Nie służą one do wymuszania ale do informowania o przeznaczeniu
> konkretnej właściwości.

Owszem, sluza do wymuszania uzywania/nieuzywania danych czlonkow klasy
w dany sposob. Nie wiem, czy Ty w ogole zdajesz sobie sprawe o czym
mowisz. Informowac to sobie mozesz w komentarzach.

>
> Problem się zaczyna przy dużym projekcie, wielu klasach dziedziczących
> (płasko, nie głębokie drzewa),
> gdy okazuje się, że protected z klasy bazowej sprawia spory problem
> przy rozwijaniu projektu.

Zly model obiektowy - co z tego? Protected generalnie nie jest uzywane
poza miejscami, gdy klasy pochodne maja "skonfigurowac" dzialanie
klasy, ktorej generalny mechanizm zawarto w bazowej. Wtedy sie
sprawdzaja. W Pythonie (w dokumentacji chocby) widzialem metody
publiczne, ktore sa przeznaczone do  nadpisania w klasach pochodnych.
One wlasnie powinny miec ustawiony modyfikator protected.

>
> Tworzy się wtedy obejście na niepotrzebne blokowanie przy pomocy klas
> friendly.

Nie wiem skad Ci sie wziely teraz klasy zaprzyjaznione.

>
> W pytonie wystarczy oznaczyć element jako protected '_' czy private
> '__' i każdy normalny programista
> zrozumie jego znaczenie, czyli nie używaj, a jak musisz to w klasach
> ściśle powiązanych i musisz być przygotowany
> na zmiany jeżeli nie ty rozwijasz pakiet z daną właściwością. Czyli
> masz to samo co w Java, tylko bez zbędnego pisania
> i bez problemów przy złożonych systemach.

Z glupimi nazwami.

>
> Hermetyzacja nie oznacza blokowania klasy przed idiotami, tylko jasne
> oznaczenie przeznaczenia klas i ich elementów.

Owszem.

> W php czy w java oznaczenie jako private nie oznacza, że nie uda się
> dostać do danej właściwości, bo można choć nie wprost (identycznie jak
> w pythonie).

Ok, ale co z tego?