Wpis z mikrobloga

#programowanie #programista15k #python
Ma ktoś jakiś dobry sposób na nauczenie się obiektówki? Wszystkie te przykłady ze zwierzątkami, pieskami i kotkami przerabiałem, ale to są tylko podstawy, a w prawdziwym kodzie dużo więcej się dzieje. Po prostu w głowie coś nie może mi przeskoczyć na ten sposób myślenia.
Od wieków pisałem proceduralnie i nigdy obiektówka nie była mi potrzebna (poza pojedynczymi przypadkami, gdzie udało się to obejść). Jak już mam Cos w tym grzebać, to jakoś sobie radzę, ale wiem, że w pełni tego nie rozumiem i potrzebuje dużo czasu by ogarnąć kod.
  • 24
@stary_kon: zakładając że teorię znasz, to może jakieś API w django zrób? Samo django też się może kiedyś przydać, a przy okazji będziesz miał sporo zabawy z OOP.
@stary_kon: Ja bym po prostu pisał kod i pakował wszystko w obiekty zachowując SRP. Poza tym korzystaj głównie z agregacji. Dziedziczenie i polimorfizm używaj tylko wtedy, gdy samo nasuwa ci się na myśl i nieużycie tych technik byłoby błędem.
Gdy zdobędziesz już trochę obycia zapoznaj się ze wzorcami projektowymi, spróbuj aplikować je w projektach jeżeli mają sens. A dalej po prostu rozkminiaj, czytaj kod innych i nie pisz obiektowo kiedy uznasz,
@croppz: No właśnie chodzi o to, że może i znam, ale nie rozumiem. Co czytam kod, to wydaje się on odmienny od tego co wydawało mi się, że rozumiem. I tak już jest ok kilku lat. Nie potrzebuję obiektówki na codzień, ale od wielkiego dzwona muszę się w to zagłębić, no i jest tego jakby coraz więcej.
@Malkof: Dzięki za tipy. Niestety w moich projektach nie mam obiektówki, tylko nieraz musze coś podłubać, albo dopisać w narzędziach z których korzystam. Jako, że ze mnie już stary koń, to po godzinach raczej rodzina niż kodowanie.
via Wykop Mobilny (Android)
  • 0
@stary_kon: Szczerze to po prostu spróbuj tak jak rozumiesz napisać jakiś program. W pewnym momencie zobaczysz, że coś się nie klei, zrobisz jeszcze raz. I tak powolutku będzie się w głowie ustawiało, aż nie kliknie.
Generalnie po prostu rób to źle do momentu, aż nie zrobisz dobrze.
zakładając że teorię znasz, to może jakieś API w django zrób? Samo django też się może kiedyś przydać, a przy okazji będziesz miał sporo zabawy z OOP.


@croppz: Jak chce się nauczyć obiektówki to przydałby się jakiś projekt gdzie rzeczywiście będzie miał jakąś bardziej skomplikowaną logikę niż CRUD.

Z api w Django i jakimś crudem to się najprawdopodobniej co najwyżej nauczy pisać kod proceduralny z wykorzystaniem obiektów. A to ma się
A to ma się do "prawdziwej" obiektówki tak jak pisanie funkcji do programowania funkcyjnego


@some_ONE: ładnie ujęte, ale tak czy inaczej jest to IMO jakiś początek. Zrobi sobie na start obiektowego cruda, potem może zacząć do tego dodawać endpointy z jakąś ambitniejszą logiką. Jak się rzuci od razu na głęboką wodę, to pewnie nawet nie będzie za bardzo wiedział od czego zacząć. ( ͡° ͜ʖ ͡°)
ale tak czy inaczej jest to IMO jakiś początek. Zrobi sobie na start obiektowego cruda, potem może zacząć do tego dodawać endpointy z jakąś ambitniejszą logiką.


@croppz: No pewnie, tak tylko się wtrąciłem, bo często panuje przekonanie, że napisanie kilku klas to już programowanie obiektowe. Chociaż czy istnieje jakaś jedna precyzyjna definicja obiektówki to też nie wiem ( ͡° ͜ʖ ͡°)

Przy czym ja sam jestem zdania,
@stary_kon: no i w sumie gdzie tu problem? Pisz proceduralnie, klasy traktuj jak struktury danych, a funkcje bardzo silnie związane z jakąś jedną strukturą umieszczaj jako metody w klasie. Dziedziczenia unikaj jak ognia, jedynie naucz się interfejsów bo są przydatne tam gdzie chcesz mieć więcej niż jedną implementacje jakiegoś zachowania. Dostaniesz w ten sposób kod lepszy i łatwiejszy w utrzymaniu niż większość kodu OOP pisanego w czasach hajpu na OOP z
@stary_kon: Zadałeś właśnie pytanie na temat object oriented designu, nie oczekuj, że dostaniesz dobra odpowiedź na wykopie, bo większość programistów nie potrafi programować, nawet jeżeli robi to zawodowo od wielu lat. xD Budowanie API niczego cię nie nauczy odnośnie object oriented designu. Po pierwsze wpisz w google hasło object-oriented design, zobacz przykłady dotyczące windy, parkingu, jak i inne problemy, które pytaja na interview. W teorii przy OOP modelujesz rzeczywistość, czyli powiedzmy
@stary_kon: > Po prostu w głowie coś nie może mi przeskoczyć na ten sposób myślenia.

Od wieków pisałem proceduralnie i nigdy obiektówka nie była mi potrzebna


@stary_kon: W programowaniu strukturalnym po prostu tworzysz funkcje, które przyjmują jako argument strukturę(obiekt). W programowaniu obiektowym zamiast tego na obiekcie wywołujesz metodę, co właśnie można przyrównać do wywalania funkcji, która przyjmuje jako jeden z argumentów referencje do tego obiektu.

Więc technicznie to żadna filozofia.
Więc technicznie to żadna filozofia. A przydaje się to do utrzymania większego porządku w kodzie, by każdy nie mógł z każdym, tylko by po bożemu mieć jakaś kontrole nad tym kto za co odpowiada.


@avr250: Ja tam nie zauważyłem większego porządku w kodzie. Raczej każdy stosuje jakieś wytrychy i sztuczki. Do tego dodajemy wielodziedziczenie i jak się zagłębiam w te struktury, to po pewnym czasie przestaję się orientować co się skąd
stary_kon - > Więc technicznie to żadna filozofia. A przydaje się to do utrzymania wi...

źródło: comment_1666182658TA8Lz1xFICKhdMag4ZREQm.jpg

Pobierz
A przydaje się to do utrzymania większego porządku w kodzie, by każdy nie mógł z każdym, tylko by po bożemu mieć jakaś kontrole nad tym kto za co odpowiada.


@avr250: Szczerze to nie widzę związku.

Co za różnica czy napiszesz:

write(file, "foo")
czy

file.write("foo")
Język ze statycznym systemem typów i tak Ci nie pozwoli wywołać funkcji na wartości o złym typie np nie zrobisz

write(7, "foo")
A porządek to kwestia modularyzacji.