Zrozumieć programowanie obiektowe - nie lada wyzwanie

0

Cześć, nigdy nie spodziewałem się, że będę pisał na tym forum w dziale Newbie - ale może jednak skoro tutaj piszę to tak musiało być?
Do czynienia z webówką mam już parę dobrych lat. Głównie siedzę w backendzie ale frontu też musialem chcąc nie chcąc się nauczyć więc bez CSS i JS znam na dość dobrym poziomie więc generalnie tak licząc to w branży siedzę już od 2014 roku czyli w sumie 4 lata, a biorąc pod uwagę że skończyłem Informatyke w tym roku (studia magisterskie) to nawet 5 lat tego doświadczenia jest. Ale nie tylko akademickiego - podczas studiów podejmowałem sporo różnych projektów, pracowałem na początku na stażu a potem na normalnym stanowisku programisty PHP. Dodam, że przed uczelnią nie miałem totalnie żadnego powiązania z informatyką, wgl jeszcze odbierając wyniki z matur byłem przekonany że pójde na jakiś kierunek humanistyczny... Przechodząc do rzeczy - chcę przerzucić się na Jave ale tego języka nie znam na tyle dobrze aby ubiegać się o pozycję Regulara (a nie ukrywam że kasowo teraz jest dość spoko) więc poszukuję różnych ofert pracy począwszy od Junior Javy Deva po Software Developera, gdzie konkretnie język nie jest wyznacznikiem.

problem jest taki, że mam problem z napisaniem projektu od zera. Czyli dostaje zadanie rekrutacyjne do wykonania i wykładam się na stworzeniu szkieletu aplikacji tj. poukładaniu klas, implementacja odpowiednich interfejsów - podzieleniu klas, oddzielenie normalnych klas od abstrakcyjnych, zastosowaniu logicznego dziedziczenia klas po sobie... Gdzie leży problem? Jak zacząć wgl rozpatrywać taką patową sytuację gdzie pomimo tylu letniego doświadczenia ciągle mam problem z zastosowaniem obiektowości w projekcie? Warto dodać że teorię znam bardzo dobrze tzn. na tyle dobrze że potrafię opisać różnice pomiędzy interfejsem a klasami abstrakcyjnymi, wzorce projektowe itd. To samo jest w momencie kiedy przychodzi mi czytać kod czyjś. Bardzo dobrze wszystko wiem jak to jest zbudowane, zdebugować dobrze kod ale przychodzi coś do czego czyli napisanie swojego modułu, aplikacji to jest lipa.

Pytam Was o radę bo może mieliście podobny problem bądź będziecie w stanie pomóc i choć trochę nakierować obecną kariere.

1

naucz się pracować wg TDD, to praktycznie wymusza poprawną hierarchię klas, ograniczenie ich odpowiedzialności, segregację interfejsów, odwrócenie zależności

0

Hej :)

Jeżeli masz magistra i czujesz się noobkiem programowania obiektowego to zastanów się czy to wina studiów czy Twoja (podpowiedź: Twoja...). Wydaje mi się jednak, że masz niską samoocenę i przesadnie się umartwiasz swoim stanem, na pewno nie jest tak źle. Większość obecnie używanych frameworków ma generatory kodu i konwencje "gdzie, co i jak" umieścić, a do tego rozwijanie jakiegokolwiek kawałka aplikacji możesz napisać wzorując się na już istniejącym kodzie - czy to w tej aplikacji czy szukając wzorców w necie. Nie ma się czego bać. W pracy nikt nie będzie się Ciebie pytał (poza HRami na rozmowie o pracę :D ) czym jest klasa abstrakcyjna itp. Po to masz głowę i znasz angielski, by umieć szukać rozwiązań swoich problemów ;)

0

Mam wrażenie że jednak brakuje tu wiedzy teoretycznej właśnie, nie uczyłeś się przypadkiem programowania z książek które zakładają że umiesz już pisać obiektowo , a nie wiesz jak użyć obiektów w danym języku. Poszukać czegoś gdzie jest to tłumaczone od zera, pamiętam że ja uczyłam się obiektowości na C++,, potem poznając inne języki stosowałam tylko już wcześniej nabyte wiadomości

0

To samo jest w momencie kiedy przychodzi mi czytać kod czyjś. Bardzo dobrze wszystko wiem jak to jest zbudowane, zdebugować dobrze kod ale przychodzi coś do czego czyli napisanie swojego modułu, aplikacji to jest lipa.

to jest bardzo dziwne albo masz na myśli jakieś małe fragmenty czyjegoś kodu.

0
Pijany Pomidor napisał(a):

dostaje zadanie rekrutacyjne do wykonania i wykładam się na stworzeniu szkieletu aplikacji tj. poukładaniu klas, implementacja odpowiednich interfejsów - podzieleniu klas, oddzielenie normalnych klas od abstrakcyjnych, zastosowaniu logicznego dziedziczenia klas po sobie... Gdzie leży problem?

Może w kolejności? Najpierw zrobiłbym interpretację naiwną, dopiero potem brałbym się za abstrakcje czy drabinki dziedziczeń. Te techniki nie są celem samym w sobie. Powinny wyrastać z praktycznej potrzeby. Piszemy program i sięgamy po takie techniki w miarę, jak się rozrasta. Wyrastają organicznie ze struktury tego, co powstaje.

Powinno się wręcz używać ich oszczędnie. W działe C# / .NET trwa właśnie (daj Boże dogasa) spór o to, czy dziedziczenie nie powinno być domyślnie wykluczane, poprzez oznaczanie klas jako sealed / final, co jest zalecane jako słuszna pratyka przez większość źródeł. Dotychczasowy przebieg tej dyskusji przypomina pojedynek z czarnym rycerzem u Monty Pythona ;)

Twój problem często występuje u ludzi z dobrą podbudowę teoretyczną, ale bez praktycznego otrzaskania. Podchodzą do tematu od niewłaściwego końca. "Złapałem siedem pokemonów-wzorców projektowych, muszę zaimplementować to i tamto - hm, jak tu wpakować Strategię, Fabrykę i Fasadę?".

Przeświadczenie, że powinniśmy najpierw zaprojektować cały "szkielet", a potem już tylko z górki - wypełnimy kolorowankę kredkami - jest ciut niezdrowe. Mało kto potrafi z góry bezbłędnie przewidzieć, jakie abstrakcje najlepiej złożą się na rozwiązanie problemu.

Warto dodać że teorię znam bardzo dobrze tzn. na tyle dobrze że potrafię opisać różnice pomiędzy interfejsem a klasami abstrakcyjnymi, wzorce projektowe itd.

Możesz być nie do zagięcia jeśli chodzi o wszystkie możliwe różnice między kluczem szwedzkim a żabką, ale to nie znaczy, że wiesz, którego kiedy użyć ;)

Odwróciłbym podejście. Może warto spróbować przy tym TDD (dobra propozycja @gsdgdf); piszemy po linii najmniejszego oporu, ale zarazem nakładamy wymóg, żeby kod był dobrze testowalny; to najczęstsza i najbardziej oczywista przyczyna, dla której przydają się abstrakcje.

0

A to nie od wersji PHP5 jest wprowadzona obiektówka, aż tak bardzo się różni względem PHP 7.2?

1 użytkowników online, w tym zalogowanych: 0, gości: 1