[PHP/JS/Teoria] Programowanie obiektowe

**zakius** · 24-01-2014 18:51

Dlatego ja planuję przed tworzeniem klasy, a nie po

poza tym tworzenie tego zestawu do pola, które jest na przykład boolem nie ma już uzasadnienia, tutaj nie ma szans, żeby coś wybuchło w międzyczasie, nie ma sensu przesadzać i tyle

Kusterek · 24-01-2014 19:01

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Dlatego ja planuję przed tworzeniem klasy, a nie po

no jeżeli tak dobrze planujesz, że nie musisz nigdy nanosić poprawek to Bogu dzięki, że nie masz zapędów jak Hitler

**zakius** · 24-01-2014 20:26

Mam, ale brak mi charyzmy...

W każdym razie, stosowanie izolacji w każdym przypadku bez wyjątku 'bo tak jest lepiej' jest nieuzasadnione. Może i 'będę to robić tylko kiedy muszę'est dość ekstremalne i lepiej się sprawdzi 'w uzasadnionych wypadkach tego nie zrobię' ale w dalszym ciągu trzymanie się tego sztywno bo tak odbiera nam w pewnym sensie władze nad kodem.

Alex Fortune · 25-01-2014 02:04

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Jak jest potrzebne to robię, ale to raczej i tak settery. Podaj mi konkretny przykład, gdzie bez zamknięcia całej klasy wszystko wybuchnie.
setValue(type v)
{
value=v;
}
type getValue()
{
return value;
}
są kompletnie bezużyteczne, setter z zablokowanym publicznym dostępem ma sens jeśli się do niego wlepi sprawdzenie poprawności, co z drugiej strony trochę narusza teoretyczną funkcję settera, który ma być bezużyteczny...
Sensownego zastosowania gettera nie widzę (oh well, jak zapomnę drugiej równości w ifie to może trochę pomóc...)

stworzyć syntetyczny obiekt? np, zamiast wołać o.setShit(z) robię o.shit = z; where's the problem

robienie na siłę niektórych rzeczy "bo konwencja" nie ma sensu, język jest naszym narzędziem, a nie panem

Pytałem jak zrobić mock, który będzie można skonfigurować do testu jednostkowego.
I btw, nie robię tego ,,bo konwencja" , tylko stosuje, ponieważ ułatwia mi to życie, pracuje nad projektem gdzie są dziesiątki commitów dziennie, masa różnego kodu, cały build process z poszczególnymi warstwami testów i tak dalej i mówię Ci po prostu z doświadczenia, że tak jest łatwiej.

@Edit
O, a np jak byś zaimplementował proxy dla interfejsu klasy macierzystej? Czytaj klasy A i B implementują interfejs I, klasa A jest Proxy dla klasy B i potrzebujesz mieć możliwość zwrotu wartości z B. Będziesz śmiecił w __set? ;]

**zakius** · 25-01-2014 02:08

Może proszę cie bardzo używaj języka praktyka, a nie teoretyka. Ja się uczę z dokumentacji i open source. Poradniki, książki, nawet głupie hinty od prowadzącego najczęściej mi przeszkadzają (zwłaszcza jak ktoś na siłę coś tłumaczy...)

Alex Fortune · 25-01-2014 02:25

Prosze ja Ciebie. Przykład z życia wzięty, prosto z mojej pracy ( oczywiście w przybliżeniu dużym ). W naszym systemie mamy klasę:

Kod :

//user.php
class User {

    public $nick;
    [...]
}

No, i jak się pewno domyślasz, aby zdobyć nick , trzeba zrobić coś takiego:

Kod :

//zewnetrzny.php
echo 'Witaj '.$user->nick.' [...]';

Wszystko fajnie.
Do czasu, kiedy management kazał nam zrobić aliasy do nicków. W skrócie każdy może założyć alias który kompletnie zastępuje nick w systemie, ale w niektórych miejscach informacja o oryginalnym nicku nadal jest potrzebna.
Do users została dodatkowo stworzona tabela users_aliases, powiązanie id_usera -> alias.

No i teraz chciałbym wiedzieć, jak wdg Ciebie to łatwo zaimplementować, bez zmieniania api ( $user->nick na np $user->alias , powody są różne - np z powodu zewnętrznych services które korzystają z tych obiektów ), bo takich referencji jest conajmniej kilkaset jeśli nie tysięcy w projekcie i pociąga to za sobą spore ryzyko.

Możesz:
a) Stworzyć metodę __get ( czytaj i tak tworzysz logikę dla pola, z tym że odwołujesz się do metody magicznej co jest bez sensu )
b) Nadpisać przy tworzeniu obiektu $nick przez alias ( ale wtedy tracisz informację o oryginalnym nicku ).

Gdybyś miał getter, wystarczyłoby zrefaktorować getNick() , postawić jednego ifa na istnienie pola $this->alias i tyle. API się nie zmienia. Działać będzie.

I jeszcze jedna sprawa. Wyobraź sobie, że mój User jest implementacją interfejsu IUser. Jak niby mam zmusić klasę user do tego aby posiadała pole $nick? Nie da się. I słusznie, bo coś takiego zabiłoby jakąkolwiek możliwość wpływania na IO do tego pola. Z pomocą przychodzą znowu gettery i settery. Bo widzisz, ja sobie mogę wtedy w IUser wpisać ,,getNick" i każda klasa go implementująca musi go jakoś zaimplementować. I nie interesuje mnie tu, czy czyta swoje własne pole prywatne, czy może kontaktuje się z marsjanami którzy wyślą go w postaci JSONa z powrotem. Ma mi zwrócić nick i tyle.

I ja rozumiem, że jeśli pisze się jakąś stronę sam, to może to kogoś jebać, bo może w razie czego pozmieniać wszystkie referencje i tyle. W wypadku projektów na skalę enterprise tak się nie da - im strona jest większa, tym ważniejszy staje się interfejs dostępu i jego niezmienność. W tym celu hermetyzacja jest wymagana.

@Edit

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Może proszę cie bardzo używaj języka praktyka, a nie teoretyka. Ja się uczę z dokumentacji i open source. Poradniki, książki, nawet głupie hinty od prowadzącego najczęściej mi przeszkadzają (zwłaszcza jak ktoś na siłę coś tłumaczy...)

Co? To był język praktyka, tego się używa kolego w codziennej pracy XD

Chodziło o coś takiego:

Kod :

interface I {

public function doSomething();

}

class A implements I {

    private $b;
 
    public function __construct(B $b){
         $this->b = $b;
    }

    public function doSomething() {
         return $this->b->doSomething();
    }

}

class B implements I {
 
    public $nick; //Twoje pole o ktorym mowisz

    public function doSomething(){
       [...coś...]
   
    }

}

**zakius** · 25-01-2014 10:02

Praktyka to kod, a nie pierdoły. Żeby mówić po polsku nie musisz wiedzieć, co to przydawka załóżmy, rzeczownik jeszcze jakoś ogarniesz, ale głębokie filmy teoretyków języka cie nie interesują.

A zmiana funkcjonalności gettera nicku na getter nicku lub aliasu w zależności od sytuacji jebie ideę getterów. To by mogła być dodatkowa metoda.

A to, że w bibliotece publicznej robisz interfejsy dla idiotów no to już jest dość normalne. Ale w projekcie wewnętrznym nie zawsze jest sens się bawić.

Bazan · 25-01-2014 14:01

Ten sam koleś o którym wspominałem o allegro powiedział nam bardzo fajną anegdotę kiedyś.

Zawsze dbaj o swój kod, nawet jeśli robisz go dla zabawy, do szuflady, dla klienta, czy na hackatonie.

Był jednym z ważnych osób na hackatonie, jako osoba testująca skrypty. Zjechali jedną z ekip bo zrobili bardzo dużo, ale na odpierdol. Tzn, wlasnie olali hermetyzacje, zabezpieczenia itp. tlumaczac sie, ze to tylko Hackaton, a w normalnej pracy zrobiliby to lepiej. Usłyszeli po tym odpowiedź po której zmienili zdanie: Dobra - jak znajde takie błędy w waszym produkcyjnym kodzie to oboje tracicie robote! Mina im wtedy troche zbledła.

Złe nawyki i olewatorstwo z pracy do szuflady prędzej czy później dobija się na jakości kodu produkcyjnego. Bo złe nawyki się utrwalają. A jak ktoś od samego początku dba o swój najbardziej jak może, będzie doceniony.

I teraz pytanie, jeśli ktoś lubi sobie programować to może to robić na trochę luźniejszych zasadach, ale jeśli liczy na to że będzie zarabiał gruby hajs jako programista, to z takim podejściem niewiele zwojuje. Poszukiwani są PROFESJONALIŚCI - w każdym calu.

@edit

Rok później ta sama ekipa, nauczeni już nauczką jaką dostali w poprzedniej edycji, pierwsze co zrobiła to zaczeli pisać testy, a dopiero później feature'y.

Sam nie ukrywam, o programowaniu dużych aplikacji nie mam pojęcia. Ale jak osoba która BARDZO WIELE zdziałała w tej branży, i może się pochwalić zarobkami na poziomie 20k zł miesięcznie, mówi mi, że o swój kod należy dbać w każdym szczególe, i być na tym punkcie bardzo uczulonym, to będę go słuchał. Bo wolę uczyć się od tych dobrych.

**zakius** · 25-01-2014 14:11

Bazan napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Poszukiwani są PROFESJONALIŚCI

Ale takich praktycznie nie ma, albo nie mogą wykazać się profesjonalną pracą bo zleceniodawca/szef ciśnie na szybkość i "ładność" produktu. To, że interfejs składa się z cukierków, a pola i metody są ułożone alfabetycznie w kodzie nie znaczy, że to jest wykonanie profesjonalne. Dbanie o kod to przede wszystkim to, żeby uodpornić produkt na spotkanie z pijaną małpą, to daje chociaż częściową odporność na użyszkodników. Oczywiście dochodzą kwestie złożoności obliczeniowej stosowanych algorytmów, wydajności ich implementacji itp
To, że do jakiegoś boola nie zrobię gettera i settera nie ma wpływu na działanie, w przeciwieństwie do większości burdelu, jaki serwują "profesjonaliści"

Alex Fortune · 26-01-2014 16:27

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Praktyka to kod, a nie pierdoły. Żeby mówić po polsku nie musisz wiedzieć, co to przydawka załóżmy, rzeczownik jeszcze jakoś ogarniesz, ale głębokie filmy teoretyków języka cie nie interesują.

A zmiana funkcjonalności gettera nicku na getter nicku lub aliasu w zależności od sytuacji jebie ideę getterów. To by mogła być dodatkowa metoda.

A to, że w bibliotece publicznej robisz interfejsy dla idiotów no to już jest dość normalne. Ale w projekcie wewnętrznym nie zawsze jest sens się bawić.

Nie, nie mogła by być, bo API ma być trwałe i zwracać ,,aktualnie używany nick" w kontekście biznesowym, czyli takim jaki sobie zażyczy management. Nadal nie powiedziałeś mi , jak byś rozwiązał ten problem. ;]

@Edit
@up
Ma. Już wyjaśniłem na przykładzie pola ,,nick", dlaczego warto wprowadzać settery i gettery, jeśli nie rozumiesz na podstawie oczywistego przykładu, to po prostu musisz się tego kiedyś nauczyć na własnej skórze, to wszystko kwestia doświadczenia ;) sam nie jestem zwolennikiem pakowania ,,formalnych rozwiązań" w wszystko co się da, ale wraz z kolejnymi swoimi krokami zrozumiałem, po co one są i dlaczego większość z nich jest naprawdę dobra.

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Praktyka to kod, a nie pierdoły. Żeby mówić po polsku nie musisz wiedzieć, co to przydawka załóżmy, rzeczownik jeszcze jakoś ogarniesz, ale głębokie filmy teoretyków języka cie nie interesują.

To co Ci napisałem to praktyka. My w pracy tak mówimy. Co w tym takiego dziwnego? Jeśli nie ogarniasz podstawowych pojęć, to już nie moja wina ;dd

**zakius** · 26-01-2014 16:39

Jeśli zleceniodawca zmienia specyfikację produkty, gdy ten jest już gotowy to już jego problem, by zapłacić za zmiany. A zmiana zachowania metody na coś kompletnie nieprzewidywalnego "bo komuś się odwidziało" to JEST burdel. Także "rób gettery bo ktoś może stwierdzić, że chciał jednak coś innego pobierać" to nie jest argument, to nie jest profesjonalne rozwiązanie. Można dorzucić w razie konieczności zachowania API bibliotekę kompatybilności, w tym wypadku faktycznie wymagane są te gettery. Ale wracając do Jeśli zleceniodawca zmienia specyfikację produkty, gdy ten jest już gotowy to już jego problem, by zapłacić za zmiany widzimy, że możemy sobie pozwolić na dłubanie w kodzie, bo rzeczony idiota płaci

Alex Fortune · 26-01-2014 16:43

zakius napisał

Cytat został ukryty, ponieważ ignorujesz tego użytkownika. Pokaż cytat.

Jeśli zleceniodawca zmienia specyfikację produkty, gdy ten jest już gotowy to już jego problem, by zapłacić za zmiany. A zmiana zachowania metody na coś kompletnie nieprzewidywalnego "bo komuś się odwidziało" to JEST burdel. Także "rób gettery bo ktoś może stwierdzić, że chciał jednak coś innego pobierać" to nie jest argument, to nie jest profesjonalne rozwiązanie. Można dorzucić w razie konieczności zachowania API bibliotekę kompatybilności, w tym wypadku faktycznie wymagane są te gettery. Ale wracając do Jeśli zleceniodawca zmienia specyfikację produkty, gdy ten jest już gotowy to już jego problem, by zapłacić za zmiany widzimy, że możemy sobie pozwolić na dłubanie w kodzie, bo rzeczony idiota płaci

Czy Ty sobie ze mnie jaja robisz? xD Ja pracuję na etat, management ma prawo powiedzieć co chce, a ja mam to zrobić bo za to mi płacą. Nie mówię o jakichś śmiesznych hehe zleceniach za dwa tysiące tylko o projektach w której wpakowało się setki tysięcy + dolców, projekty posiadające baze milionów użytkowników , których api jest wykorzystywane już na wielu stronach i tak dalej . Doskonale wiem jakie są realia zleceń i wiem , że tak naprawdę tam nie ma to żadnego znaczenia ( byle szybciej i taniej ), ale jeśli ktoś chce pracować przy trochę wyższej półce, musi znać pewne techniki które ułatwiają mu życie ( i życie innych dookoła ), inaczej będzie ciężko to po prostu ogarnąć ;]

**zakius** · 26-01-2014 17:10

No i to nie jest w najmniejszym stopniu profesjonalizm. To jest paranoja, zrobić szybko. Później połowę kodu usunąć i napisać na nowo, bo klient sam nie wie, czego chce. I to wszystko w ramach śmiesznej pensji na etat. Tak być nie powinno. Jakby ludzie się szanowali to by wyglądało inaczej, ale niestety. Kasa ważniejsza niż zasady. Ja wolę robić fizycznie, niż się tak sprzedawać

Rollercoster · 26-01-2014 17:24

Kusterek · 26-01-2014 19:49

zakius - Vegeta działu programowania ;D

zeby nie bylo offtopa podpisuję się pod Havarana. Teraz czytam książkę "Mistrz czystego kodu". Bardzo fajna, koles opowiada swoją historię, pokazuje jak kiedyś się programowało a to było bardzo ciekawe :P No ale wracając do meritum, koleś na swoim doświadczeniu pisze, że najważniejsze jest być profesjonalnym w tym co sie robi, nawet jak srasz. Nim wcześniej to się zrozumie i zastosuje, tym ta dupa w której będziemy będzie płytsza.

Temat: [PHP/JS/Teoria] Programowanie obiektowe

Narzędzia tematu

Oceń ten temat

Informacje o temacie

Użytkownicy przeglądający temat

Podobne tematy

$$ Praca o PHP, prosta strona i aplikacja w PHP, kupie $$ PILNE

[C++] Programowanie obiektowe - zadanie z dziedziczenia

[C++ / programowanie obiektowe] #include class, naglowkow i bibliotek

Skrypt PHP - przesyłanie danych z formularza php do pliku .txt

Programowanie strukturalne i obiektowe

Zakładki

Zakładki

Zasady postowania