[PHP/JS/Teoria] Programowanie obiektowe

Zachęcony różnymi informacjami o HTML5 postanowiłem wreszcie spełnić swoje marzenia i nauczyć pisać strony i aplikacje internetowe. Jak na typowego humana przystało idzie baaardzo opornie, więc możecie spodziewać się wielu pytań ;) W tym temacie chciałem jednak poprosić o wytłumaczenie mi na czym polega programowanie obiektowe

Niestety artykuł z wiki niewiele mówi osobie stykającej się z terminem pierwszy raz, brzmi jakoś abstrakcyjnie i sprawia, że człowiek ma większy mętlik w głowie. Czy ktoś może wytłumaczyć na czym programowanie obiektowe/zorientowane obiektowo (bo to to samo?) faktycznie polega? Dlaczego jest takie użyteczne? Byłbym wdzięczny za każdą próbę wbicia mi do głowy na czym to polega, jeśli dysponujecie jakimiś artykułami lub nawet kodami (W PHP lub JS bo tylko te w tej chwili jako tako kojarzę) to proszę o podsyłanie bo szczerze mówiąc mam wrażenie, że stoję przed wielką górą, której nie dostrzegam przez mgłę

Z góry dzięki i pozdrawiam

Też się podbiję pod kolegę i proponuje założenie odrębnego tematu z PHP wyłącznie. Jakby ktoś ogarniał i mógł zrobić lekcje programowania w php to już w ogóle było by super. Jakby @Killavus ; chciał albo mógł znowu zrobić coś na podobiznę wcześniejszego tematu z programowania.

Po pierwsze - musisz znać podstawowe pojęcia jak funkcje , zmienne, instrukcje warunkowe i tak dalej. Bez tego nie masz po co patrzeć na programowanie obiektowe.

W skrócie - programowanie obiektowe wprowadza pojęcie ,,obiektu" jako logicznej jednostki wykonującej zadanie. Obiekt jest definiowany przez tzw klasę, która definiuje jego pola ( właściwości ) i metody ( sposoby oddziaływania na obiekt ).

Aby prościej to zobrazować, pokażę Ci przykład z życia wzięty:

Kod:

---

<?php

class Czlowiek {

    private $zjedzone; //Co zjadl nasz czlowiek?
    public function __construct(){ //Metoda __construct to w PHP tzw "konstruktor", automatycznie wywolywany przy stworzeniu obiektu
        $this->zjedzone = array();
    }

//Klasa definiuje czlowieka
    public function zjedz($jedzenie) {
        $this->zjedzone[] = $jedzenie;
    }


}

$ja = new Czlowiek();
$ty = new Czlowiek();
$ja->zjedz('ciastko');
$ty->zjedz('schabowy');

?>

---

Odpowiednio wykorzystywane pozwala na znaczne zwiększenie czytelności kodu i zależności miedzy logicznymi jednostkami a także ułatwia ponowne wykorzystanie kodu.

Programowanie obiektowe a programowanie obiektowo zorientowane to 2 różne rzeczy, ale nie powinieneś sobie zawracać tym głowy, najpierw naucz się w ogóle programować, dopiero później z czasem poczytaj o technikach programowania bo na początku i tak nie będziesz wiedział o co chodzi. Warto też dodać że programowanie to nie tyle co znajomość języka, a umiejętność planowania rozwiązania problemu i to tutaj jest najważniejsze - język to tylko narzędzie. Uprzedzając najprawdopodobniejsze pytanie - programowania najlepiej uczyć się programując, nie ma innej opcji, nauka samej teorii niczego Ci nie da jeżeli nie będziesz kodował.

To może je spróbuję tak zdeczka wprowadzić. Nie będzie to może szczyt wiedzy programistycznej ale dla laika najlepiej tlumaczyć na chłopski rozum. Nie znam PHP jeżeli chodzi o programowanie obiektowe, dlatego moje nauczanie będę prowadził w C#, jednak uważam że będzie to na tyle proste że zrozumiesz a w formie ćwiczenia stworzysz podobny kod w PHP.

Programowanie obiektowe jest to sposób programowania, gdzie używasz obiektów. Czym są obiekty? No tak naprawdę obiektem może być wszystko: przedmioty, figury, ludzie, samochody. Te ostatnie są bardzo prostym przykładem więc na ich podstawie omówię najważniejsze kwestie. Samochodów może być dużo, każdy z nich posiada wspólne cechy, czyli każdy z nich jest jakiejś marki, ma jakiś kolor, jakiś silnik i jakiś przebieg. Znamy wszystkie parametry (marka, kolor, silnik, przebieg), ale nie znamy ich wartości - to jest własnie KLASA. Teraz spośród wszystkich samochodów możemy stworzyć jeden, taki który posiada kolor, silnik i markę - jest to OBIEKT. Obiekty tak jak już mówiłem, tworzymy używając klasy. Zatem od czego zaczynamy naszą zabawę z programowaniem obiektowym? Od napisania naszej klasy!
Oto jak wygląda klasa o jakiej pisaliśmy: nazwa Samochód, parametry: marka, kolor, silnik, przebieg.

Kod:

---

class Samochod
{
public string marka;
public string kolor;
public double silnik;
public int przebieg;
}

---

Wszystko co dotyczy tej klasy, musi zawierać się w klamerkach { }.
Jak widzimy, tworzenie klasy rozpoczynamy od wyrazu class, następnie nazwa. Logiczne, nie ma co tłumaczyć.
W klamrach już jest ciekawiej, widzimy

Kod:

---

public string kolor;

---

Po kolei: public - o tym później - przy hermetyzacji :) string - typ naszego pola (parametru) kolor -nazwa naszego pola.

Mamy już klasę, teraz aby zrobić nasz obiekt potrzebny nam będzie KONSTRUKTOR. Czym jest konstruktor? jest to metoda, która wywołuje się przy tworzeniu obiektu. Może brzmieć strasznie, ale to nic trudnego. Metoda to funkcja w klasie. Metoda to tak łopatologicznie: zadanie jakie może realizować klasa np. jedź(), albo zapal_swiatla().
Jak stworzyć konstruktor, stworzyć metodę o takiej samej nazwie co klasa! czyli dopisać pod polami:

Kod:

---

public Samochod()
{
}

---

Kiedy mamy już klasę z konstruktorem, możemy stworzyć obiekt! Jak go stworzyć? W kodzie programu (nie w klasie!) napisać instrukcję:

Kod:

---

Somochod auto1 = new Samochod();

---

To jest nasz pierwszy obiekt! Ale zaraz, nasz samochód jeszcze nie ma ani koloru, ani marki, nic nie ma. Co robimy? Można by po kolei odwoływać się do pól i je ustawiać np:

Kod:

---

auto1.marka = "Toyota";
auto1.kolor = "czerwony";
....

---

Można ale to jest brzydkie. Możemy to wszystko zrobić w konstruktorze!
Tworzymy więc kolejny KONSTRUKTOR Z ARGUMENTAMI Czym są argumenty? są to już konkretne wartości naszego samochodu. Konstruktor ten robimy np. tak:

Kod:

---

public Samochod(string _marka, string _kolor, double _silnik, int _przebieg)
{
    marka = _marka;
    kolor = _kolor;
    silnik = _silnik;
    przebieg = _przebieg;
}

---

A jak stworzyć dzięki niemu obiekt?
Dokładnie tak jak poprzednio, ale w nawiasach wpisujemy cechy naszego samochodu, w takiej samej kolejnosci.

Kod:

---

Samochod auto2 = new Samochod("Toyota", "czerwony", 1.6, 10000);

---

Teraz temu naszemu samochodowi, możemy powierzyć jakieś zadania, prawda? Jednak te zadania trzeba mu najpierw zapisać w klasie tworząc metody. Zróbmy prostą metodę jedz(), która wypisze nam na ekran jakiś tekst. Pod konstruktorami dopiszmy:

Kod:

---

public jedz()
{
    Console.WriteLine("Bruuuuuum");
}

---

Jak rozkazać samochodowi żeby jechał? Bardzo podobnie jak "brzydko" przypisywalismy wartości do pól, mianowicie piszemy nazwę naszego obiektu, a potem po kropce nazwę metody z nawiasami:

Kod:

---

auto2.jedz();

---

Co się pojawi na ekranie? To Twoja praca domowa, koniec lekcji, odrób pracę domową i stwórz podobny kod w PHP. Jak będziesz chciał dalej się pouczyć to mogę Ci wytłumaczyć na czym polegają rzeczy ściśle związane z programowaniem obiektowym, mianowicie: dzidziczenie, hermetyzacja, polimorfizm.

Pozdrawiam! :)

Dobra napisałeś co to jest, ale nie wiadomo czym to się różni od zwykłego programowania. (Wiem, że teraz ci co ogarniają temat pocisną mnie że obiektowe to też zwykłe programowanie).

Napiszę w sumie to co wyczytałem w kursie C++. Czyli, dlaczego powstało programowanie obiektowe:

Kiedyś, nie było czegoś takiego jak klasa. Były tylko zmienne i funkcje. I tak np. Jak chciało się posortować tablicę liczb. Tworzyło się funkcję sortuj która jako argument pobierała tablicę do posortowania, oraz opcjonalnie sposób - malejąco/rosnąco.

Funkcje taką wykonywało się:

Kod PHP:

---

$tablica = sortuj($tablica,'malejaco'); // Zmiennej $tablica przypisz wynik funkcji sortuj ktorej kazalismy posortowac tablice malejaco

---

Było to nie przyjazne człowiekowi, gdyż patrząc w naszym świecie np. na naszą drukarkę - jak ona drukuje, to mówi się, że: Drukarka wydrukowała dokument. A w programowaniu mówiło się wtedy: Drukowanie następuje na drukarce, i drukuje dokument. Czyli, najpierw jest czynność a później coś co tą czynność wykonuje.

Programowanie obiektowe odwraca ten proces na bliższy naszemu rozumowaniu.

Dziś tworzy się klasę drukarka, która ma funkcję drukuj, której przekazuje się tylko 1 argument - sposób sortowania.

I tak np. teraz: Zamiast wykonywać $tablica = sortuj($tablica,'malejaco');, wykonuje się:

Kod:

---

$tablica->sortuj('malejaco');

---

Ten pierwszy parametr funkcji który tym razem zniknął jest z góry przypisany do tego co znajduje się przed strzałką - czyli naszego obiektu (zmiennej $tablica), który tworzy się tak jak wcześniej napisał @Havaran .

W takim sposobie programowania lepiej widać co na czym jest wykonywane. Po pierwsze - bierzesz zmienną tablica, po drugie, wykonujesz na niej akcję sortuj.



Druga zaleta programowania obiektowego to możliwość łatwiejszej rozbudowy.

Jeśli masz już duży projekt i zaawansowany - np baze danych wszystkich modeli samochodow swojej marki.
Wszystkie te modele to nic innego jak nowa zmienna typu klasowego (nazwa utworzonej klasy), posiadaja takie same parametry jak klasa. I jeśli już stworzyłeś 140 modeli, jak chciałbyś dodać im dodatkowy parametr, np. pomysłodawca wyglądu - imie osoby ktora wymyslila ten wyglad. Musiałbyś normalnie wyedytować okolo 140 linijek i dopisac im nowego wlasciciela. Tworzac zmienna typu klasowego, wystarczy ze w klasie dopiszesz dodatkowe pole (zmienna). I wszystkie obiekty tego typu beda mogly miec przypisanego autora.



Do tego dochodzą takie pojecia jak:
Hermetyzacja danych, dziedziczenie, interfejsy, polimorfizm. To juz grubsze zagadnienia do znalezienia opisu w necie.

Hermetyzacja to gówno. O ile rozumiem, że w konkretnych przypadkach pojedyncze pole lepiej zabezpieczyć, to w ogólności to jest bez sensu. Jeśli ktoś inny zajrzy do mojego kodu i go nie rozumie i coś zepsuje to jego problem... Z reszta wspólna praca nad kodem to trochę podchodzi pod poligamię...

Cytuj:

---

zakius napisał

Hermetyzacja to gówno. O ile rozumiem, że w konkretnych przypadkach pojedyncze pole lepiej zabezpieczyć, to w ogólności to jest bez sensu. Jeśli ktoś inny zajrzy do mojego kodu i go nie rozumie i coś zepsuje to jego problem... Z reszta wspólna praca nad kodem to trochę podchodzi pod poligamię...

---

Nie masz racji. Hermetyzacja jest jedną z najważniejszych rzeczy w OOP, dostęp do pól jest nawiązaniem statycznym = niepodatnym na modyfikację oraz rozwiązaniem dość ciężkim do testowania, toteż złą praktyką jest tworzenie pól publicznych. ZAWSZE z zewnątrz tworzymy settery i gettery aby dać możliwość nadpisania funkcjonalności.

Tja, ale jak potrzebuję tylko dostępu bezpośredniego to jest to nieźle irytujące. Rozumiem jak setter musi dbać o poprawność danych to zakładam private żeby nie zapomnieć, ale no bez przesady żeby wszystko i zawsze było prywatne lub chronione...

Cytuj:

---

zakius napisał

Hermetyzacja to gówno. O ile rozumiem, że w konkretnych przypadkach pojedyncze pole lepiej zabezpieczyć, to w ogólności to jest bez sensu. Jeśli ktoś inny zajrzy do mojego kodu i go nie rozumie i coś zepsuje to jego problem... Z reszta wspólna praca nad kodem to trochę podchodzi pod poligamię...

---

Dzisiaj tworzenie aplikacji to tylko praca grupowa. Dziś już nie ma jednoosobowych twórców aplikacji komercyjnych. Czasy uber geeków siedzących 24h mineły. Potwierdzone info, od specjalisty ds. jakości kodu, i zarządzania zespołami programistów w grupie Allegro.

Chcesz coś zawojować i pracować jako programista? - Jesteś zmuszony pracować wspólnie nad kodem.

Tez nie zrozumialem tego hejta na pracę w kilka osób nad jednym kodem.
Tak samo ten hejt na stosowanie hermetyzacji, każdy programista chyba chce aby jego kod był jak najlepszy. Skoro hermentyzacja uodparnia na błędy to dlaczego jej nie stosować? Tym bardziej, że po pewnym czasie takie ograniczanie zasięgu pól wchodzi w nawyk.

Dodatkowy pierdyliard linii kodu i mess. Jeśli jakieś IDE mi to samo dorobi no to już trudno, ale jak mam klepać to ręcznie to tylko gdzie jest mi niezbędne.
A praca w kilka osób nad jednym kodem to tylko gdy ja jestem szefem i mogę tyrać ludzi, że coś źle robią

Cytuj:

---

zakius napisał

Dodatkowy pierdyliard linii kodu i mess. Jeśli jakieś IDE mi to samo dorobi no to już trudno, ale jak mam klepać to ręcznie to tylko gdzie jest mi niezbędne.
A praca w kilka osób nad jednym kodem to tylko gdy ja jestem szefem i mogę tyrać ludzi, że coś źle robią

---

Okej kolego, wobec tego masz klase z polami publicznymi. jak chcesz:
a) stworzyć mock do takiej klasy
b) mieć możliwość zmiany zachowania przy accessowaniu pola

Chętnie posłucham ;]

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

Cytuj:

---

zakius napisał

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

---

A sytuacja taka:

Zrobiłem sobie publiczne pole. Odwołałem się do o.shit w 50 miejscach, w 4 plikach, i gdzieś jeszcze gdzie już nawet nie pamiętam.

Nagle po kilku dniach pracy widzę, że o.shit nie powinno mieć nigdy wartości 3.14.

Teraz muszę dodać getter i setter i ustawić mu odpowiedniego ifa czy coś co obsłuży tą liczbę. I znaleźć wszystkie wystąpienia o.shit i zamienić na o.getShit();

Podczas gdy gdybym od początku zrobił setter i getter. Wystarczu dopisać jednego ifa.

Teraz jak masz po 10 takich pól w 3 klasach, robota się kumuluje.

A wystarczyło zrobić to na początku. Lenistwo początkowe później się odbija.

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

Cytuj:

---

zakius napisał

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

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.

Cytuj:

---

zakius napisał

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? ;]

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ę:

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

Cytuj:

---

zakius napisał

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ś...]
 
    }

}

---

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.

Cytuj:

---

Bazan napisał

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"

Cytuj:

---

zakius napisał

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.

Cytuj:

---

zakius napisał

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

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

Cytuj:

---

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ąć ;]

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ć

http://1.bp.blogspot.com/-Rc8k_D3yYo...rt-Popcorn.gif

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.

A z drugiej strony mówią, że jak klient jest nieogarnięty i zamówił coś, co mu nie działa to my mamy się głowić, co on namieszał. profesjonalizm where

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ć

---

Przeciwnie. Twoim zdaniem jako profesjonalista jest dopasowanie się pod klienta i wykonanie tego co on potrzebuje. Co do ,,ramy śmiesznej pensji na etat" to juz się nie wypowiem, bo podejrzewam, że zarabiam więcej od Ciebie ;)

I niestety, ale ja już nie będe tłumaczył Ci dlaczego robi się tak a nie inaczej. Ja nie robię tego, że klient. Ja robie to dla siebie. Bo sprawia mi przyjemność pisanie kodu, który jest bardzo elastyczny i mogę bardzo łatwo rozbudować - takiego, który prezentuje sobą dużą wartość. To jest właśnie profesjonalizm. I na tym zakończmy, jak nabierzesz nieco doświadczenia to zrozumiesz ;)

Mi sprawia przyjemność pisanie kodu,a nie zgadywane czego chce klient kiedy on sam tego nie wie. Jak wie czego potrzebuje to problemu nie ma, nawet jeśli to kompletny kretynizm (patrz 90% stron internetowych różnych firm...) to przynajmniej są jasno określone wymagania

Cytuj:

---

zakius napisał

Mi sprawia przyjemność pisanie kodu,a nie zgadywane czego chce klient kiedy on sam tego nie wie. Jak wie czego potrzebuje to problemu nie ma, nawet jeśli to kompletny kretynizm (patrz 90% stron internetowych różnych firm...) to przynajmniej są jasno określone wymagania

---

No ale to wcale nie jest tak że klient nie wie. Realia biznesowe zmieniają sie ekstremalnie szybko, a im bardziej potrafisz sie do tego dopasować - tym lepiej. I nadal nie rozumiem, czemu forsujesz rozwiązanie, które jest mniej elastyczne ( co Ci już pokazałem na przykładzie aliasów ) , a dokładnie tak samo proste w użyciu jak moje ( i wcale nie pisze się tego dłużej - u mnie gettery i settery to kwestia alt insert i dwa razy enter w IDE ;] )

@Edit
Strzelam że kolega @zakius ; miał po prostu przykre doświadczenia z klientami na rynku freelancerów. Też miałem i wiem jak to wygląda, ale tak postępując tylko utrudniasz sobie robotę, a co do samego rynku freelancerów się już nie wypowiem ponad tyle, że m.in dlatego zrezygnowałem z bycia freelancerem i w ogóle z pracy w Polsce.

Twoje rozwiązanie jest elastyczne jeśli albo w pierwotnej wersji oddałeś do api specjalną funkcję, której modyfikacja nie obniży zrozumiałości kodu, albo gdy porzucisz sensowne nazywanie metod i podstawową konwencję tworzenia tychże getterów w momencie zmiany wymagań. Pierwszy wypadek jest mało prawdopodobny, drugi nie jest poprawny z punktu widzenia czystości kodu, jeśli metoda nazywa się getNick() i klasa posiada pole nick to nie jest zbyt intuicyjne zwracanie przez nią zawartości pola alias. Nawet na miejscu klienta wolałbym przeprowadzić proste zamien wszystkie niż mieć burdel w kodzie zarówno swoim jak i zewnętrznym.
Załóżmy nawet, że gettery nie są takie złe, niech już będzie. Ale wracając do tego boola. Pewnie zaraz powiesz, że w każdej chwili może się okazać, że dana metoda ma zwracać zawartość pola tylko gdy inny warunek nie jest spełniony, w przeciwnym wypadku wasze prawdę albo coś w tym stylu. Jednak znów to nie jest typowy getter tylko metoda dodatkowa.

IDE... No cóż, tak długo, jak tym IDE nie jest visual studio to nawet nie mam ochoty mordować, chociaż w wypadku php nie znalazłem żadnego, które dałoby mi jakąkolwiek korzyść

Cytuj:

---

zakius napisał

IDE... No cóż, tak długo, jak tym IDE nie jest visual studio to nawet nie mam ochoty mordować, chociaż w wypadku php nie znalazłem żadnego, które dałoby mi jakąkolwiek korzyść

---

Nie wiem co Ty masz do PHPwych IDE. Jest Phpstorm, numer jeden wg mnie, jest aptana, jest netbeans. Moim zdaniem to właśnie PHP mają najlepsze IDE :)

Netbeans sprawdza się do javy, ale w php nie dawał mi nic ponad to, co mam w npp (bo nawiasy i klamry i tak zawsze sam robię, a reszty nie potrafił ogarnąć). Próbowałem wielu rzeczy, ale po prostu nie miałem siły zastanawiać się, co tu zrobić żeby mi to w końcu zaczęło pomagać zamiast przeszkadzać. Teraz mam więcej czasu to może spróbuję jeszcze raz.

Btw, eclipse ogarnia jak zamykam sam dodany przez niego nawias, ale klamry już nie i mi zostają 2 i muszę poprawiać... Niesamowite...
Ile to trzeba czasu poświęcić, żeby narzędzie zaczęło działać

Cytuj:

---

Rollercoster napisał

Nie wiem co Ty masz do PHPwych IDE. Jest Phpstorm, numer jeden wg mnie, jest aptana, jest netbeans. Moim zdaniem to właśnie PHP mają najlepsze IDE :)

---

PHPStorm to zdecydowanie lider.

Cytuj:

---

zakius napisał

Twoje rozwiązanie jest elastyczne jeśli albo w pierwotnej wersji oddałeś do api specjalną funkcję, której modyfikacja nie obniży zrozumiałości kodu, albo gdy porzucisz sensowne nazywanie metod i podstawową konwencję tworzenia tychże getterów w momencie zmiany wymagań.

---

O jakiej funkcji mówisz? Ja oddałem tylko getter getNick() ;)

Cytuj:

---

zakius napisał

Pierwszy wypadek jest mało prawdopodobny, drugi nie jest poprawny z punktu widzenia czystości kodu, jeśli metoda nazywa się getNick() i klasa posiada pole nick to nie jest zbyt intuicyjne zwracanie przez nią zawartości pola alias.

---

Nieprawda. Dla mnie jest to wręcz bajecznie intuicyjne - Metoda getNick() ma zwrócić nick w kontekście biznesowym, słyszałeś kiedyś pojęcie logika biznesowa? Właśnie dlatego się tak nazywa, bo definiuje to, co nazywamy "biznesem", czyli działaniami na rzecz end-userów. W naszym wypadku, getNick() ma zwrócić nick używany w sytemie, a domyślnym nickiem jest alias o ile takowy istnieje :)

@EDIT
Rozwinę ten punkt jeszcze. A powiedz mi, czy jeśli wdg Ciebie nicki byłyby pobierane z jakiegoś zewnętrznego api, albo z jakiegoś cachea, albo nie wiem, z chuj wie jakiego źródła, to metoda nie powinna nazywać się getNick()? Jeśli myślisz że gettery sa tylko po to aby opakowywać pola, to jesteś w błędzie ^^

Cytuj:

---

zakius napisał

Nawet na miejscu klienta wolałbym przeprowadzić proste zamien wszystkie niż mieć burdel w kodzie zarówno swoim jak i zewnętrznym.

---

Powiedz to naszym wszystkim kontrahentom , którzy używają api przez jakiś SOAP.

Cytuj:

---

zakius napisał

Załóżmy nawet, że gettery nie są takie złe, niech już będzie. Ale wracając do tego boola. Pewnie zaraz powiesz, że w każdej chwili może się okazać, że dana metoda ma zwracać zawartość pola tylko gdy inny warunek nie jest spełniony, w przeciwnym wypadku wasze prawdę albo coś w tym stylu. Jednak znów to nie jest typowy getter tylko metoda dodatkowa.

---

Jak to powiedział mój szef gdy rozmawialiśmy o sposobach programowania : ,,nigdy nie wiesz co jutro będzie". Nigdy nie wiesz kiedy logikę z boola będziesz musiał zamienić na jakiś call zewnętrzny ;] i niestety to się sprawdza.

Cytuj:

---

zakius napisał

IDE... No cóż, tak długo, jak tym IDE nie jest visual studio to nawet nie mam ochoty mordować, chociaż w wypadku php nie znalazłem żadnego, które dałoby mi jakąkolwiek korzyść

---

PHPStorm wspomniany jest genialny, mam tam absolutnie wszystko :) a jeszcze jest Netbeans i parę innych.

Cytuj:

---

zakius napisał

Netbeans sprawdza się do javy, ale w php nie dawał mi nic ponad to, co mam w npp (bo nawiasy i klamry i tak zawsze sam robię, a reszty nie potrafił ogarnąć). Próbowałem wielu rzeczy, ale po prostu nie miałem siły zastanawiać się, co tu zrobić żeby mi to w końcu zaczęło pomagać zamiast przeszkadzać. Teraz mam więcej czasu to może spróbuję jeszcze raz.

Btw, eclipse ogarnia jak zamykam sam dodany przez niego nawias, ale klamry już nie i mi zostają 2 i muszę poprawiać... Niesamowite...
Ile to trzeba czasu poświęcić, żeby narzędzie zaczęło działać

---

Dlatego polecam PHP storm.
phpstorm> aptana> netbeans

Sam spędziłem trochę czasu na konfiguracji, ale teraz na prawdę przyjemnie się kodzi.
Integracja z gitem, automatyczne wysyłanie na serwer i maaaasa innych przydatnych pierdół.
Czekam jeszcze na nową kartę graficzną i monitor, wtedy praca będzie jeszcze przyjemniejsza :)

Jasne, że metoda robiąca cokolwiek poza zwróc wartość pola się przydaje. Za to właśnie taka, która robi tylko to jest dość... No właśnie. Poza tym w tym przykładzie to by było getDisplayName(załóżmy) które zwraca alias jeśli istnieje, w przeciwnym wypadku nick. I tutaj wszystko się trzyma kupy. W każdym razie, udostępnianie do bezpośrednio do API metod wyłącznie zwracających wartość pola może prowadzić do takich dziwnych rzeczy. Co zrobisz, jeśli wewnątrz swojej części kodu potrzebujesz ZAWSZE nick, ale nie masz dostępu bezpośrednio do pola? Klepiesz nową metodę i po swojej stronie zmieniasz wywołania? To jest bez sensu i nieelastyczne. Z drugiej strony opakowywanie prostego gettera w dodatkową funkcję, która zwraca jedynie zwrot z tego gettera to już kompletny cyrk... I co z tym zrobić, żeby było czysto, działało i biedny klient nie musiał się pocić, bo jednak chce coś inaczej?

Cytuj:

---

zakius napisał

Jasne, że metoda robiąca cokolwiek poza zwróc wartość pola się przydaje. Za to właśnie taka, która robi tylko to jest dość... No właśnie.

---

Nie wprowadzasz tego po to, abyś "dorabiał sobie roboty". Wprowadzasz to po to, bo w razie jeśli będziesz musiał to zmienić, nie musiał nadwyrężać się robotą ;) Design robi się aby uniknąć czegoś, a nie aby zaleczać :P

Cytuj:

---

zakius napisał

Poza tym w tym przykładzie to by było getDisplayName(załóżmy)

---

Na to samo wychodzi, to jest przykład gettera.

Cytuj:

---

zakius napisał

Co zrobisz, jeśli wewnątrz swojej części kodu potrzebujesz ZAWSZE nick, ale nie masz dostępu bezpośrednio do pola? Klepiesz nową metodę i po swojej stronie zmieniasz wywołania? To jest bez sensu i nieelastyczne.

---

A jak myślisz, co jest bardziej prawdopodobne - że po zmianie będzie potrzebna nowa funkcjonalność czy stara? Ta stara może być użyta co najwyżej w paru miejscach . W tym celu mogę stworzyć ,,getOriginalNickname" i zmienić tam gdzie potrzebuje zmienić wykorzystanie logiki biznesowej ( co jest jedynym usprawiedliwieniem dla zmiany użytkowania interfejsu z zewnątrz, jakby się zastanowić, to ma to sens :) ).

Cytuj:

---

zakius napisał

Z drugiej strony opakowywanie prostego gettera w dodatkową funkcję, która zwraca jedynie zwrot z tego gettera to już kompletny cyrk... I co z tym zrobić, żeby było czysto, działało i biedny klient nie musiał się pocić, bo jednak chce coś inaczej?

---

Kod:

---

<?php
interface IGotNick {

public function getNick();

}
class X implements IGotNick {

private $nick;

public function getNick(){

return $this->nick;

}

}

---

Na prawdę dla Ciebie to takie trudne? XD dla mnie to jest z stoperem w ręku niecałe 10 sekund, a jeśli potem potrzebuję zmienić logikę zwracania nicku robię to bez bólu i refaktorowania całego projektu. Easy.

Aha, jeszcze jedna ważna sprawa - jeśli musisz zmieniać implementację korzystającą z interfejsu przy zmianie tegoż interfejsu, coś robisz źle. Dlaczego np mój klient miałby zmieniać swój interfejs pokazujący najnowszych użytkowników na swojej stronie np, tylko dlatego że ja wprowadziłem jakieś aliasy? :) To bez sensu.

Nie wiem, rób jak chcesz. Rozumiem Cię , bo sam tak myślałem parę lat temu, to wszystko przychodzi z czasem, zaczyna się rzeczy takie jak rozdzielanie odpowiedzialności , zależność od abstrakcji i hermetyzacja coraz lepiej rozumieć i doceniać ich zalety. I nie mówię tego by Cię jakoś obrazić czy coś, po prostu chciałem zwrócić uwagę na to, że sam przez to przechodziłem ;)

A no bo to ON wprowadził aliasy do specyfikacji gdy wszystko już było gotowe. Jasne, jeśli płaci za to, że getNick() mu zwraca liczbę postów to już inna sprawa. Ale jeśli niczego takiego nie wymaga to intuicyjne nazwy > 'intuicyjne' nazwy

Cytuj:

---

zakius napisał

A no bo to ON wprowadził aliasy do specyfikacji gdy wszystko już było gotowe. Jasne, jeśli płaci za to, że getNick() mu zwraca liczbę postów to już inna sprawa. Ale jeśli niczego takiego nie wymaga to intuicyjne nazwy > 'intuicyjne' nazwy

---

Przestań zwalać winę na klienta. On wprowadził, bo chciał coś nowego do produktu, czemu się tego tak czepiasz? getNick() w kontekście biznesowym w momencie wprowadzenia aliasów zaczyna znaczyć coś innego i jako tako ma to zwracać. Mi za to płacą, więc to robię, a Ty jeśli masz zamiar robić wielkie burdy o to , że klient wprowadził coś nowego do projektu po paru latach ( bo realia biznesowe sie zmieniają ), to z każdej firmy po prostu wylecisz xD

@Edit
Wspomniane aliasy wprowadzono 4 lata po stworzeniu serwisu, uważasz że powinnem opierdalać pracodawcę za to, że chcą wprowadzać innowacyjność do swojego produktu? XD

@Edit2
Jeszcze jedna sprawa. Poczytaj o logice biznesowej. To naprawdę ważny koncept, bo nie programujemy dla zabawy, tylko dlatego aby wykonywać dane operacje które coś znaczą w Naszym świecie. ;)

Tylko ten klient musi się liczyć z tym, że będzie miał burdel. W tym wypadku ewentualne zastosowanie zmodyfikowanego getNick() zamiast pobrania wartości pola nick najwyżej wywoła trochę wstydu, ale może być znacznie gorzej.

Cytuj:

---

zakius napisał

Tylko ten klient musi się liczyć z tym, że będzie miał burdel. W tym wypadku ewentualne zastosowanie zmodyfikowanego getNick() zamiast pobrania wartości pola nick najwyżej wywoła trochę wstydu, ale może być znacznie gorzej.

---

Dlaczego? Jeśli getNick() zwraca aktualny nick używany w sytemie, to dlaczego wdg Ciebie jest to burdel? xD Dla mnie głupim by było zdobywać przez getNick() == "stasiu" kiedy tak naprawdę nick który chciałby zobaczyć user to ,,zbysiu" :) Nie każda implementacja jest ,,prosta" w tym sensie , że nick zwraca pole nick i trzeba się z tym niestety liczyć, po to mamy właśnie takie rzeczy jak SRP i SOLID ogółem, aby być elastyczni na to.

W sytuacji, gdy nick jest używany WYŁĄCZNIE jeśli alias nie istnieje to problemu nie ma. Ale jeśli istnieje alias, a potrzebuje wartość pola nick może się zdarzyć wypadek.

Cytuj:

---

zakius napisał

W sytuacji, gdy nick jest używany WYŁĄCZNIE jeśli alias nie istnieje to problemu nie ma. Ale jeśli istnieje alias, a potrzebuje wartość pola nick może się zdarzyć wypadek.

---

Jakiego rodzaju? :)
Jeśli potrzebujesz wartość pola nick po tym gdy do systemu są wprowadzone te całe aliasy, to prawdopodobnie tylko w paru miejscach i tam faktycznie należy zmienić implementację ( np dodać getOriginalNickname() ), właśnie dlatego że tutaj logika biznesowa się zmieniła - w tych miejscach z pobierz nick użytkownika logika zmienia się na pobierz pierwszy nick użytkownika jaki kiedykolwiek miał, co jak najbardizej usprawiedliwia zmianę wykorzystania implementacji. ;)

Tylko jak mówiłem, realistycznie patrząc, takich zmian będzie conajwyżej parę w całym kodzie ( np u mnie były tylko trzy na cały projekt, zmieniliśmy getter na właśnie taki jak wyżej podałem ) a reszta sobie działała na nowej implementacji pobierania nicku. Profit ;)

Nawet raz zapomnisz zmienia powiedzmy. Albo ktoś nowy nie ogarnie tego cyrku, w końcu ciężko sprawdzać implementację każdego gettera. No bo co może robić metoda getNick(). A akurat nowy się spieszy, bo deadline blisko, nie zrobi testu z aliasem i buba. Jasne, że świat się nie zawali w tym wypadku, ale na pewno nie jest to rozwiązanie idealne.

Cytuj:

---

zakius napisał

Nawet raz zapomnisz zmienia powiedzmy. Albo ktoś nowy nie ogarnie tego cyrku, w końcu ciężko sprawdzać implementację każdego gettera. No bo co może robić metoda getNick(). A akurat nowy się spieszy, bo deadline blisko, nie zrobi testu z aliasem i buba. Jasne, że świat się nie zawali w tym wypadku, ale na pewno nie jest to rozwiązanie idealne.

---

Jak to co? Zwracać nick który jest używany w systemie :) Ty myślisz o tym w kategorii obiektu, a ja myślę w ramach implementacji. To teraz zastanowmy się co jest lepsze? Moje spojrzenie jest takie, że getNick() ma mi zwrócić nick w znaczeniu tego, co widzisz na stronie, i tak naprawdę chuj mnie interesuje jak to działa ( prywatne pole czy jakaś szalona magia ). Twoim zdaniem jak jest getNick() to ma zwracać pole. A na stronie pokazuje się coś innego, kurczę, ciekawe dlaczego? A , bo są jakieś aliasy. I nagle okazuje się że getNick() tak naprawdę nie zwraca nicku :)))

To dalej nie ma sensu. Z czasem się przestawisz , ręczę ;p naprawdę polecam przestać myśleć o obiektach jako o ich wewnętrznym stanie a o jako implementacji interfejsu i starania się separować odpowiedzialność, bo jeśli nie, zaczyna się burdel.

Enough said, dobranoc ;d

Dziękuję wszystkim za rozjaśnienie sytuacji. Choć programowanie obiektowe wciąż jest dla mnie lekką abstrakcją i nie wyobrażam sobie bym go używał w praktyce (no cóż, w tej chwili w głowie mi siedzą malutkie kody typu 'hello world') to przynajmniej natrafiając na nie w czyimś kodzie nie wywalą oczu a ogarnę co tam się dzieje