Czy programowanie OO jest tak samo ważne, jak firmy zajmujące się rekrutacją? [Zamknięte]

Właśnie kończę studia magisterskie (z informatyki) i staram się o pracę. Zauważyłem, że wiele firm prosi o zrozumienie orientacji obiektowej. Popularne pytania podczas wywiadu dotyczą dziedziczenia, polimorfizmu, akcesoriów itp.

Czy OO jest naprawdę tak ważne? Miałem nawet rozmowę o pracę programistyczną w C, a połowa wywiadu to OO.

Czy w prawdziwym świecie, opracowując prawdziwe aplikacje, prawie zawsze używana jest orientacja obiektowa? Czy DUŻO używane są kluczowe funkcje, takie jak polimorfizm?

Myślę, że moje pytanie wynika z jednej z moich słabości. Chociaż wiem o OO, wydaje mi się, że nie jestem w stanie wprowadzić go zbyt wiele do moich programów.

OOP to paradygmat, który pozwala Twojemu programowi rosnąć bez niemożliwości utrzymania / zrozumienia. Jest to punkt, którego uczniowie prawie nigdy nie dostają, ponieważ po prostu wykonują małe projekty trwające od dwóch tygodni do maksymalnie dwóch miesięcy.

Ten krótki okres nie jest wystarczający do wyjaśnienia celu OOP, zwłaszcza jeśli osoby biorące udział w projekcie są początkującymi. Ale trzymanie się modeli jest kluczowe dla dużych projektów, powiedziałbym, że> 50 000 linii kodu. OOP nie jest jedynym rozwiązaniem tego problemu, ale jest to najczęściej stosowane w branży.

Właśnie dlatego ludzie chcą, abyś poznał OOP.

Dodam z doświadczenia, że ​​prawie wszyscy młodsi programiści mają poważne wady w modelowaniu i OOP. Większość z nich umie pisać klasy, dziedziczyć po nich i takie podstawowe rzeczy, ale nie myślą w „OOP” i nie wykorzystują tego w niewłaściwy sposób. Dlatego każdy poważny rekruter zawsze będzie sprawdzał twoje kompetencje w domenie OOP.

Ponieważ tych rzeczy nie uczy się w szkole, istnieje ogromna różnorodność wiedzy między różnymi kandydatami. I bądźmy szczerzy: nie sądzę, aby ktoś, kto ma słabą wiedzę na temat OOP, mógł pracować nad jakimkolwiek dużym projektem, po prostu dlatego, że wymagałoby to więcej czasu dla wiodących deweloperów, aby zarządzać tymi ludźmi, niż po prostu napisać sam kod.

Jeśli nie myślisz jeszcze o „OOP”, sugerowałbym, abyś przeczytał kilka książek na ten temat i złożył podanie w towarzystwie, które nie ma naprawdę dużych projektów; aby przyzwyczaić się do OOP, wykonując użyteczną pracę dla swojego pracodawcy (i dopóki on / ona daje ci pensję, będzie to również przydatne dla ciebie).

EDYCJA: ha, i dodałbym, że już napisałem kod OOP w C, nawet jeśli nie jest to najczęstsze użycie C, jest to możliwe przy dużej wiedzy. Musisz tylko ręcznie zbudować vtables.

A za techniką OOP kryje się coś: projektowanie oprogramowania. Projektowanie oprogramowania jest naprawdę pomocne, zarówno w języku C, jak iw innych językach. Wielu rekruterów przetestuje twoje kompetencje w zakresie projektowania oprogramowania i pytanie OOP jest do tego dobre, ale OOP nie jest najważniejszą rzeczą, która jest tutaj testowana. Dlatego masz te pytania nawet dla pracy w C.

Przytłaczającym problemem związanym z programowaniem komputerowym jest obsługa złożoności, a współczesne programy mogą być naprawdę bardzo złożone, a wydaje się to tylko rosnąć.

Duża część pracy wykonanej w inżynierii oprogramowania nietrywialnych programów komputerowych koncentruje się na oswajaniu złożoności i sprawia, że ​​jest ona dostępna dla jak największej liczby osób, nie poświęcając najpierw czasu na naukę.

Przykłady:

• Modularyzacja: programowo upraszczasz programy dzięki modułom kodu, w których każdy moduł niewiele wie o innych modułach (zamiast np. Routingu rysowania ikon myszy można bezpośrednio manipulować buforami kart sieciowych).
• Interfejsy API: podają prostą ścieżkę użytkowania złożonych programów stojących za interfejsami API. Po otwarciu pliku nie ma znaczenia, że ​​udziały sieciowe są obsługiwane inaczej niż na dysku USB. Interfejs API jest taki sam.
• Orientacja obiektowa. Pozwala to ponownie wykorzystać istniejący kod i sprawić, by działał w sposób przejrzysty z dodawanym nowym kodem, a jednocześnie ukrywał całą złożoność.

Innymi słowy, znajomość wielu sztuczek jest niezbędna, jeśli chcesz pracować na nie trywialnych programach, samodzielnie lub (najprawdopodobniej) z innymi.

Tak, głównie dlatego, że być może dwie najpopularniejsze platformy programistyczne używane w programowaniu komercyjnym (Java i .NET) są zorientowane obiektowo, co oznacza, że ​​tak, OO jest często używane (w tym polimorfizm, dziedziczenie i wszystko inne).

Firmy nie dbają szczególnie o orientację obiektową jako technologię - nie jest to ideologia, dbają o ludzi, którzy mogą opracować rozwiązania swoich problemów w sposób zgodny ze strategią IT.

Ale nie martwiłbym się zbytnio poczuciem słabości. Bez lekceważenia twojego wykształcenia większość ludzi w świecie komercyjnym nie widzi programistów kończących studia (na żadnym poziomie) jako gotowy artykuł. Pozostało jeszcze wiele do nauczenia się i jest to zrozumiałe (prawdopodobnie lepsze przez firmy niż studentów).

Podobnie jak w prawdziwym życiu, rzeczywiste programowanie różni się od teoretycznego.

Tak, jeśli utrzymujesz dopracowanie paradygmatu OO i zawsze zapominasz, możesz lepiej pisać kod, który jest zarządzalny, zrozumiały i łatwo rozszerzalny.

Niestety, prawdziwy świat ma to:

• presja czasu projektu
• członkowie zespołu zorientowani proceduralnie
• zespoły zlokalizowane w różnych lokalizacjach, wielu dostawców
• starszy kod nie ma żadnej orientacji
• tak długo, jak to działa, niektórzy dbają o sposób pisania kodu
• nawet jeśli kod nie działa, motywacją jest go naprawić, a nie „OO”
• moduły, ograniczenia platformy, frameworki, które po prostu nie pozwalają robić dobrego OO

W prawdziwej pracy musisz pracować z powyższymi zagadnieniami. Brzmi to demoralizująco. Ale potraktuj to jak awans. Firmy zatrudniające przywiązują zbyt dużą wagę do OO podczas zatrudniania. Łatwo zrozumieć, dlaczego. Jedynym sposobem, w jaki mogą przetestować kandydata, jest pytanie o zrozumienie OO. I niestety wielu kandydatów po prostu wyrzuca te pytania przed stawieniem się na rozmowę kwalifikacyjną.

Prawdziwe OO przychodzi powoli. Pomaga to w dalszym czytaniu i poprawianiu go z czasem.

Po ukończeniu studiów licencjackich miałem takie same odczucia, a pierwsza książka : wzorce projektowe to świetna książka, która pokazała mi, dlaczego i jak OOP ma zastosowanie w aplikacjach rzeczywistych . Szczerze polecam rzucić okiem, jest napisany w naprawdę zabawny sposób i zawiera wiele ważnych argumentów, dlaczego podejście OOP jest pożądane podczas pracy z ciągle zmieniającymi się systemami na większą skalę.

Nawet w przypadku niektórych zadań w C możesz potrzebować znać projektowanie obiektowe (i prawdopodobnie być w tym lepszy, niż gdyby kompilator to zrobił dla Ciebie), o czym świadczy ostatnia seria artykułów na temat projektowania obiektowego w jądrze Linux. ( Część 1 , Część 2 )

GTK + wykorzystuje również wiele wzorców obiektowych.

Muszę wyrazić pewne spory co do tego, że OO jest wszystkim - można powiedzieć, że OO pozwala budować miasta, ale programy proceduralne są cegiełkami.

Aby udzielić mojej odpowiedzi w formie analogii, potrzeba ogólnych przedmiotów, żołnierz potrzebuje procedur. Gdy zdobędziesz wystarczająco dużo szczegółów w OO, znajdziesz procedury, a jeśli to jest twoja wiedza i jesteś wystarczająco dobry, nie martw się o OO, ponieważ łatwo jest komuś napisać ten kod do gry OO:

-findBestMove
-makeBestMove
-waitForPlayerInput

ale wtedy ktoś musi napisać kod za -findBestMove i możesz być pewien, że to nie tylko:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

Z drugiej strony, jeśli nie wiesz, jak odczytać kod OO, martw się. Ponieważ możesz być pewien (prawie), że Twój kod będzie bałaganił z obiektami jakiegoś rodzaju. Chyba że pracujesz nad starszym gigantem 12000 globalnych żołnierzy i 1200 linii „modułów”, które obecnie utrzymuję.

Jon Hopkins napisał:

Tak, głównie dlatego, że być może dwie najpopularniejsze platformy programistyczne używane w programowaniu komercyjnym (Java i .NET) są zorientowane obiektowo, co oznacza, że ​​tak, OO jest często używane (w tym polimorfizm, dziedziczenie i wszystko inne).

Co właściwie chciałem powiedzieć, ale to nie tylko Java i .Net, C ++ jest wszędzie, Objective-C jest w całym OSX, wszystkie fajne dzieciaki robią Ruby lub Python, i wszystkie te rzeczy i wiele innych więcej skupia się na orientacji obiektowej. Wiele nowszych języków obsługuje wiele języków, więc coś w rodzaju F # jest przede wszystkim językiem funkcjonalnym, ale obsługuje także orientację obiektową. Jest wszędzie, a przynajmniej trochę zrozumienia jest bardzo przydatne. Nie przejmuj się jednak zbytnio tym, że właśnie ukończone kursy uniwersyteckie oznaczają, że możesz zacząć uczyć się programowania kodu w prawdziwym świecie :)

Programowałem już od dłuższego czasu i uważam, że pojęcia OO są przydatne nawet podczas programowania w C - nawet jeśli w testach prawdopodobnie nie opisałbym tych pojęć w najdrobniejszych szczegółach. W pewnym momencie stworzyłem nawet język OO, choć podstawowy, aby omijać koncepcje i czerpać przyjemność z OO z nowego punktu widzenia.

BTW, C ++ zrobiło ogromny i brzydki bałagan OO, podczas gdy Cel C robi to dobrze.

Dzięki wywiadom stały się horrorem - z obu stron stołu. Większość ankietowanych jest przez nich przerażona. Większość menedżerów ds. Rekrutacji jest zaskoczona liczbą osób, które nie zdają nawet bardzo podstawowych testów programowych.

To powiedziawszy, w branży oprogramowania działają obecnie ogromne worki na śmieci, które nie znają NIC, a jednak oczekują świata od potencjalnych pracowników.

Nauka OOP nie jest tak przydatna jak nauka oprogramowania. Idź przeczytaj Code Complete 2 .

Jasne, że jest to przydatne narzędzie, ale samo OOP jest naprawdę małe. Ogólnie rzecz biorąc, gdy firmy i rekruterzy mówią „OOP”, mają na myśli „rozwój oprogramowania”. Jest używany jako ogólny termin.

Prawdziwi rekruterzy zauważą różnicę między wiedzą, jak tworzyć oprogramowanie i dopasowaniem pola wyboru „Ma 3 lata w OOP”.

Odpowiedź brzmi tak, jak zauważyło kilka innych osób.

ALE, jeśli chcesz pracować na stosach proceduralnego kodu spaghetti spoza OO, możesz to również znaleźć. Myślę, że wolisz pracę OO.

EDYCJA: Wybacz mój przypadek cynizmu rewolwerowca i poczucia humoru. Jak powiedział Raynos, tylko dlatego, że coś jest OO, nie oznacza, że ​​jest dobre. Właściwe stosowanie OO wymaga prawdziwej pracy i przemyśleń; samo wystąpienie tego nie oznacza automatycznie, że aplikacja jest dobrze wykonana. I odwrotnie, jestem pewien, że jest tam dobrze napisany kod proceduralny. Moje doświadczenie w korporacyjnych sklepach IT w latach 90. i 2000. było takie, że napisano dużo złego kodu i prawdopodobnie nadal istnieje. Ale bliżej pytania OP, zauważyłem, że mądrzejsi programiści, gdy mają szansę, przechodzą na więcej systemów OO.

OO jest podstawową podstawą, na której budowane są inne techniki. Kluczową kwestią jest najpierw pełne zrozumienie różnicy między typem (klasą) a instancją tego typu. Nie próbuj czytać dalej bez pełnego zrozumienia tego (myśląc, że stanie się to jasne później), ponieważ będziesz musiał przeczytać resztę od nowa, gdy złapiesz wizję.

Kiedy już to zrozumiesz, nigdy nie będziesz chciał się bez tego obejść. Nie jestem purystą, jeśli chodzi o enkapsulację, wzory, ramy itp. W pracy musisz dostosować się do różnych poglądów i koncepcji. Wymienię niektóre moje wcześniejsze doświadczenia zawodowe:

W jednej firmie moi rówieśnicy chcieli jak najwięcej leniwego ładowania (puste konstruktory, nieporęczne właściwości, które wszędzie musiały sprawdzać wartości zerowe). Budowali internetowe obiekty serwerowe, które żyły krótko.

Następna praca była zupełnie odwrotna. Obiekty mieszkały w aplikacji komputerowej (opartej na programie Excel). Jak najwięcej inicjalizacji powinno być w konstruktorze (lub jednym z wielu przeciążeń konstruktora). Puste konstruktory nie były dozwolone, ponieważ puste obiekty nie miały prawa istnienia (co utrudniało przetrwanie). Ponadto musiałem dostosować się do ich „standardów stylu kodowania” (gdzie otwierać nawiasy, dodawać białe znaki po komentarzach itp.), Ponieważ mój kod nie mógłby zostać wpisany, jeśli nie przejdzie przez cop-style.

Obecnie pracuję w firmie, w której żaden z programistów nigdy nie próbował zrozumieć OO. Trudno wyrazić, jak bardzo to było frustrujące. Musiałem poprawić swoje umiejętności Grep, w rzeczywistości mam makro HotScripts przypisane do mojego klawisza F12, aby wykonać grep na zaznaczonym tekście. Oszczędzę innych frustracji ...

Gdy zdobędziesz umiejętności OO, będziesz prawie uczulony na spaghetti! Jednak we wszystkich przypadkach, OO - lub nie, bądź cierpliwy i dostosuj się. Niechętnie „wyrzuć to i zacznij od nowa”. Twój szef raczej wybierze cię, jeśli chodzi o wyrzucanie. Niestety „zarabianie pieniędzy” jest ważniejsze niż elegancki kod.

Przepraszam za długą odpowiedź, ale starałem się pokryć większość zakresu twojego pytania :-)

OOP nie jest ważne ze względu na siebie, ale ze względu na to, co zabiera ze sobą. Coś, co dotyczy zdolności do abstrakcyjnego i izolowania, grupowania rzeczy razem, odsłania tylko te części, które są wymagane do interakcji.

Jest to powszechna technika inżynierii zwana „modularyzacją”, która pozwala tworzyć złożone systemy jako agregację prostszych, bez konieczności dbania o każdy szczegół na wysokim poziomie, i które wymagają wymiany komponentów, nawet bez ich dokładnego podobnie.

Te „koncepcje inżynieryjne” próbowano utrzymać w rozwoju oprogramowania od czasu, gdy sam produkt stał się większy niż „zdolność pojedynczego programisty”, wymagając w ten sposób sposobu zmuszenia programistów do pracy nad niezależnymi elementami i umożliwienia tym elementom współdziałać ze sobą.

To powiedziawszy, zasady te niekoniecznie znajdują się tylko w OOP (jeśli teoria obliczeń jest prawidłowa, istnieją nieskończone możliwości uzyskania takich wyników).

OOP jest po prostu udana próba umieścić te rzeczy razem, dając do tych ogólnych (takich jak moduły, enkapsulacji, podstawienie) bardziej precyzyjne definicje i wyszukanym konceptualizacji o tych definicji (wzorów), które można zmieścić w językach programowania.

Pomyśl o OOP najpierw nie jako „ funkcję językową ”, ale jako „ wspólny leksykon ”, który zmusza inżynierów oprogramowania do projektowania oprogramowania.

Fakt, że dany język ma lub nie ma prymitywów, które bezpośrednio egzekwują ten leksykon, zapewniając - na przykład - że „kapsułka” nie zostanie przypadkowo otwarta przez tego, kto nie powinien tego robić, jest drugorzędnym aspektem projektowania OOP. Dlatego nawet duże projekty C są często „zarządzane jako” OOP, nawet jeśli sam język nie oferuje bezpośredniego wsparcia dla tego.

Zaletą wszystkiego, czego nie można rozpoznać, dopóki rozmiar projektu nie pozostanie w zasięgu pojedynczego dewelopera w zrozumieniu i śledzeniu wszystkiego, co robi (w rzeczywistości w takich sytuacjach może to być nawet postrzegane jako „narzut”) lub w małej grupie rozwijającej coś w krótki okres. I to jest główny powód, dla którego juniorzy, którzy studiowali OOP pod kątem „funkcji językowej”, często źle interpretują go, tworząc źle zaprojektowany kod.

To, w jaki sposób OOP pasuje do języków, zależy od tego, jak projektanci języków interpretują zasadę OOP we własnej konstrukcji.

Tak więc „enkapsulacja” w C ++ staje się „prywatnymi członkami” (a „kapsuła” staje się klasą), „podstawienie” staje się nadpisaniem funkcji wirtualnych lub parametryzacją / specjalizacją szablonu itp., Natomiast w D kapsułka jest „modułem” (i podstawienie idzie poprzez zajęcia itp.), dzięki czemu pewien paradygmat lub wzorzec jest dostępny bezpośrednio w danym języku, a nie w innym itd.

To, czego rekruterzy szukają, zadając pytanie OOP, to po prostu sprawdzić swoją zdolność do abstrakcyjnego i świadomego projektowania oprogramowania dla przyszłych dużych projektów i rozwoju. OOP, dla nich to po prostu „słownik”, który, jak przypuszczali, ty i oni znacie, abyście mogli porozmawiać o innych bardziej ogólnych sprawach lub skonkretyzować je w konkretnej implementacji.

Język zorientowany obiektowo pomaga zachować projekt zorientowany obiektowo w kodzie, co jest dobre. Ale prawdą jest również, że taki projekt można uzyskać w dowolnym innym języku paradygmatu: przyczyną popularności (szczególnie wśród firm) języków OO jest prawdopodobnie komercyjny sukces java i c #.

Gdyby pan Gates założył firmę we właściwy sposób, zapewne studiowalibyśmy SCHEME przed ubieganiem się o pracę.

Krótka odpowiedź brzmi: tak

Dłuższa wersja, dlaczego czujesz lub masz dylemat, dlaczego jest tak ważna, tylko dlatego, że nie pracowałeś nad żadnymi projektami lub wdrożeniami, które mają jakiś cel. Jest to całkowicie poprawne w klasach, aby mieć przykłady na temat samochodów, a następnie rozszerzyć je na samochody, ciężarówki ... ale kiedy wskakujesz do rozwoju oprogramowania, jest to rozwiązanie ukierunkowane na ułatwienie niektórych zadań. Gdyby tak nie było OO, wszyscy pisaliby podobne kody w bazie kodów lubcodziennie wymyślać koła. Wyobraź sobie, jaki byłby bałagan, gdyby zanurzyć się w takiej bazie kodu, aby coś naprawić. Przykłady w klasie służą do niejasnej definicji lub przedstawienia, w jaki sposób / dlaczego to się dzieje. Prawdziwy test jest gotowy, gdy zaczynasz budować swoją aplikację, bez wątpienia wszystko, co mogłoby być strasznie używane, ale daleko waży zdrowie psychiczne ze względu na jego jasne i zwięzłe użycie. Lepiej więc zacznij pracę na tych słabych obszarach, abyś nie wyrzucał kodów koszmarów.

To zależy. Jednym z powodów, dla których musisz znać OO, ponieważ jest to lingua franca świata programowania. Jak wskazuje inna odpowiedź, prawie każdy główny język jest w pewnym sensie OO, co oznacza, że ​​w zasadzie każda firma, która mogłaby cię zatrudnić, używa języka OO. Czy kiedykolwiek próbowałeś zatrudnić programistów OCaml? To niemożliwe; pula talentów jest za mała. Jeśli założyłeś firmę za pomocą OCaml, a Twoja firma odniesie sukces, nie będziesz w stanie wystarczająco szybko zatrudnić programistów i przestaniesz działać. Dlatego prawie każda firma z więcej niż 3 programistami używa języka OO, a aby komunikować się ze współpracownikami i korzystać z bibliotek platformy, musisz znać OO.

W zależności od konkretnego języka, którego używa firma, dziedziczenie i polimorfizm są albo niezwykle ważne, albo tylko umiarkowanie istotne. Nie można nic zrobić w Javie bez wyeliminowania 10 wzorców projektowych GoF i struktury wstrzykiwania zależności. Java jest jednym z najczęściej używanych języków, dlatego zasady OO są naprawdę ważne dla wielu firm korzystających z Java.

Jeśli firma używa nowoczesnego hybrydowego języka OO / funkcjonalnego, który zawiera lambdy i wskaźniki funkcji, takie jak Scala lub C #, dziedziczenie nagle staje się mniej ważne, ponieważ masz funkcje wyższego rzędu do obsługi wielu naprawdę prostych rzeczy, które w innym przypadku wymagałyby wielu ceremonia. Jednak nadal musisz być w stanie pracować z rzeczami OO, ponieważ większość używanych bibliotek będzie pisana w sposób OO.

Jeśli dziedziczenie i polimorfizm nie są ważne dla firmy, nadal możesz zadawać pytania OO, ponieważ:

• Przeprowadza się wywiad z osobą HR, która nie wie nic o programowaniu i zadaje pytania poza listą kontrolną. Czy masz 3 lata X, wielozadaniowość itp.
• Przeprowadza się wywiad z inżynierem, który chce się upewnić, że nie mieszkasz pod kamieniem. OO to lingua franca, więc zadamy ci pobieżne pytania na ten temat.
• Przeprowadza się wywiad z inżynierem, który nie jest zbyt biegły w przeprowadzaniu wywiadów. Ogólnie rzecz biorąc, inżynierowie lubią ciekawostki i złożoność, więc będziesz mieć wiele pytań na temat polimorfizmu, dziedziczenia i wzorców projektowych GoF tylko dlatego, że te rzeczy są interesujące dla osoby przeprowadzającej wywiad.

Jednym słowem „Tak”.

Może ci się wydawać, że znasz teorię, ale musisz napisać kod i wprowadzić go w życie. Istnieją - dosłownie - tysiące przykładów i ćwiczeń dostępnych online.