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
Wersja do druku
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
no jeżeli tak dobrze planujesz, że nie musisz nigdy nanosić poprawek to Bogu dzięki, że nie masz zapędów jak HitlerCytuj:
zakius napisał
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.
Pytałem jak zrobić mock, który będzie można skonfigurować do testu jednostkowego.Cytuj:
zakius napisał
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? ;]
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...)
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ę:
No, i jak się pewno domyślasz, aby zdobyć nick , trzeba zrobić coś takiego:Kod://user.php
class User {
public $nick;
[...]
}
Wszystko fajnie.Kod://zewnetrzny.php
echo 'Witaj '.$user->nick.' [...]';
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
Co? To był język praktyka, tego się używa kolego w codziennej pracy XDCytuj:
zakius napisał
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ś...]
}
}
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ć.
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.
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 itpCytuj:
Bazan napisał
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"
Cytuj:
zakius napisał
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.
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 ;ddCytuj:
zakius napisał
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ąć ;]Cytuj:
zakius napisał
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ć
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.