Czy obiekty zostały dostarczone pod kątem ponownego wykorzystania kodu?


17

Często słyszałem, jak mówiono, że obiekty nie zostały dostarczone pod względem ponownego wykorzystania kodu. Czy sie zgadzasz? Jeśli uważasz, że nie, dlaczego nie?


4
Nigdy nie słyszałem, żeby ktoś tak powiedział ...
TheLQ

2
@ Nie sądzę, żebym rzeczywiście słyszał, jak ktoś to powiedział, ale przeczytałem to.
George Marian,

Ponowne użycie nie jest jedyną zaletą OOP.
Nikt

2
„Czy obiekty zostały dostarczone pod kątem ponownego wykorzystania kodu?” -> Tylko jeśli uwierzyłeś sprzedawcom OOP z dawnych czasów (czy to w latach 60.? Zapomniałem)
Steven Evers

Odpowiedzi:


18

Nie, niekoniecznie.

Obiekty zapewniają lepszą semantykę, organizację kodu / funkcjonalności i, być może, łatwość użycia.

Dobrze zaprojektowane biblioteki zapewniają obietnicę ponownego użycia kodu, a nie same obiekty.


No tak. Ale czy obiekty pomogły projektantom bibliotek, zapewniając im opcje ułatwiające ich ponowne wykorzystanie? Uważam, że mają, a więc obiekty zostały dostarczone ulepszony ponownego wykorzystania.
Jules

@Jules Ja też lubię debatować tylko ze względu na debatę. Nie argumentowałbym, że obiekty nie ułatwiły projektowania bibliotek. Twierdzę, że prawidłowe użycie twoich narzędzi prowadzi do właściwych rezultatów.
George Marian

7

Szczerze mówiąc, nie jestem pewien, czy „ponowne użycie kodu” jest tym, czego naprawdę chce (a przynajmniej powinno być). Moją filozofią są „komponenty oprogramowania”, co oznacza lepszą łatwość konserwacji dzięki dobrym interfejsom i unikaniu niepotrzebnego łączenia. „Ponowne użycie kodu” jest jedną z rzeczy, które czasem się z tego nie wywiązują - niepotrzebnie powielony kod jest znakiem, że źle zorganizowałeś rzeczy i oczywiście utrzymanie go jest trudne.

Aby odpowiedzieć na pytanie nieco bardziej bezpośrednio, istnieje zbiór całkiem dobrych narzędzi do unikania powtarzania się: dziedziczenie, cechy, delegowanie, funkcje wyższego rzędu itp. Spośród nich ludzie mylą dziedziczenie z OO jako całością - i oni również mają tendencję do nadużywania go, jeśli mnie zapytacie. Może stąd bierze się klimat „OO do bani”: znajdowanie dziedzictwa utknęło tam, gdzie nie ma naturalnego prawa być :)


Ponowne użycie kodu jest zdecydowanie celem, gdy można uniknąć poświęcenia jego jakości
Casebash

1
Ponowne użycie kodu nie jest jednak celem samym w sobie. Ponowne użycie to inne słowo określające sprzężenie. W związku z tym należy ostrożnie podejść do ponownego użycia. Wygląda na to, że wielu programistów zapomina o tym. Chcą odłączonych systemów, ale odwracają się i starają się używać istniejących klas wszędzie.
Andy,

5

Nie, „obiekty” nie sprawiły, że ponowne użycie kodu stało się łatwiejsze lub powszechniejsze. Te same obawy, które uniemożliwiają ponowne użycie kodu w programie modułowym (projektowanie, testowanie i dokumentowanie interfejsu API ogólnego przeznaczenia wymaga znacznie większego wysiłku z góry niż pisanie jednorazowej procedury, a jack wszystkich transakcji może być master of none - logika przeznaczona do ponownego wykorzystania może nie być dobrze zoptymalizowana pod kątem zastosowań, do których jest rzeczywiście stosowana) mają zastosowanie do programów OO, z dodatkową obawą, że źle zaprojektowany model obiektowy może utrudnić ponowne użycie w inny sposób wielokrotnego użytku kod.

OO to przydatna abstrakcja na wiele problemów, ale uważaj na szum z lat 80. i 90.: nie rozwiązuje w magiczny sposób podstawowych problemów naszego handlu, a nie robi gofrów dla ciebie podczas snu.


5

Nie oczekuję, że WSZYSTKIE obiekty zostaną ponownie wykorzystane, ale mamy wiele obiektów, które wykorzystamy w wielu różnych projektach. Mamy również obiekty, które po prostu ponownie wykorzystują jeden projekt. Często konsumujemy te same obiekty biznesowe (lub obiekty do przesyłania danych), a także obiekty logiki biznesowej z aplikacji komputerowej Click-Once, aplikacji internetowej i aplikacji telefonicznej dla tego samego projektu.

Gdzie słyszałeś, że OO nie zapewnia ponownego wykorzystania? A jakie było uzasadnienie? Być może konstrukcja ich obiektów zmusiła ich do takiej sytuacji ...


4
Różne artykuły. Z własnego doświadczenia uczynienie obiektu wielokrotnego użytku wcale nie jest bardzo łatwe
Casebash

3

Niektórzy programiści będą kopiować i wklejać w dowolnym języku i stylu.

Naprawdę dobrzy programiści mogą uniknąć kopiowania i wklejania w prawie każdym języku.

Uważam, że wzorce OO zwykle zachęcają do ponownego użycia. Widziałem kod Java napisany w stylu innym niż OO (w którym dane zostały oddzielone od kodu z powodu kiepskiego ORM), a ponowne użycie było naprawdę nieszczęśliwe - ale w OO ci sami programiści wykonali lepszą pracę przy projektowaniu ( i ponowne użycie).

Również w przypadkach, w których używamy wzorców innych niż oo lub antyterpleksów, takich jak setery / gettery, instrukcje przełączników, anonimowe klasy wewnętrzne, ogromne funkcje i tym podobne, widziałem, jak ponowne użycie kodu spada, a płyta rozszerzeń rośnie ... znacznie.

ps. Wiem, że ludzie będą mieli problemy z poprzednim akapitem, więc wyjaśnię trochę.

Setery i gettery powodują problemy z OO, ponieważ pozwalają ci operować na elementach obiektu (obiekt powinien manipulować jego własnymi elementami). To rozprowadza kod działający na twojej klasie wśród innych klas, wymagając od ciebie kopiowania funkcjonalności wokół setera / gettera . Dotyczy to również właściwości - tylko dlatego, że właściwości są łatwiejsze, nie czyni ich „dobrymi” we wszystkich sytuacjach.

Kod w Anonimowych klasach wewnętrznych nie może być w ogóle ponownie użyty, a ludzie zapominają, że wiele rzeczy (jak słuchacze) może i powinno być pełnoprawnymi klasami - dotyczy to również zamknięć! Jeśli użyłeś anonimowej klasy wewnętrznej do zaimplementowania czegoś w rodzaju detektora, istnieje większe prawdopodobieństwo, że po prostu skopiujesz i wkleisz implementację, niż wypakujesz kod do metody lub jej własnej klasy i zamiast tego wywołasz ją. Zamknięcia mogą również poprawić możliwość ponownego użycia - zależy to tylko od sposobu ich użycia.

W wielu przypadkach dostępne funkcje kształtują strukturę kodu. OO ma jeszcze większą moc, jeśli chodzi o pomoc w wizualizacji całego kodu i jego interakcji, ale to kolejne pytanie.


2

Przedmioty nie mają więcej zdolności do ponownego użycia kodu niż wspinacz po schodach lub inny sprzęt fitness może spowodować utratę wagi. Programiści muszą być zmotywowani do właściwego korzystania z narzędzi.

Gdy zespoły programowe przywiążą większą wagę do ponownego wykorzystywania przetestowanego kodu niż do zachowania wszystkich szczegółów w głowie, zobaczysz znacznie więcej drobnoziarnistych obiektów i metod, a tym samym więcej ponownego użycia kodu.


2

tak

OOP daje więcej możliwości ponownego wykorzystania kodu

Nie

nie ma srebrnej kuli

To zależy

na to, co w to wkładasz i czego w zamian oczekiwałeś!


1

Tak. Dobre programowanie obiektowe promuje rozdzielenie problemów, niskie sprzężenie, wysoką spójność i ukrywanie informacji. Wszystko to ma kluczowe znaczenie dla kodu wielokrotnego użytku.

Twierdziłbym, że główną zaletą OOP jest modułowość i modyfikowalność, a nie ponowne użycie, ale to inna kwestia.


4
Zgadzam się, że obiekty sprawiają, że kod jest ładniejszy, ale niestety tak dużej części moich obiektów nie można ponownie użyć.
Zbyt częste

2
@casebase +1 Jednak powiedziałbym, że uczynienie obiektów wielokrotnego użytku oznacza nadmierną komplikację sytuacji (obiektu).
George Marian,

Nie wszystko będzie można ponownie wykorzystać. Większość rzeczy nie. Jednak niskie sprzężenie, ukrywanie informacji itp. Są warunkami wstępnymi do ponownego użycia, a obiekt je promuje.
Fishtoaster,

2
@ Fishtoaster: równie dobrze możesz powiedzieć, że poruszanie się samochodem jest warunkiem wstępnym do pracy, a promowanie go pochylni promuje. Jest to technicznie prawdziwe, ale mało prawdopodobne jest, aby coś zmieniło poza przypadkowymi przypadkami: jeśli potrzebujesz i chcesz ponownie użyć, dostaniesz to, OO lub nie; jeśli tego nie zrobisz, spełnienie wymagań nie sprawi, że stanie się to przypadkowo.
Shog9

@Pan. C- Nie jestem pewien, czy podążam za tobą. Mówiłem tylko, że rzeczy, które wspiera OOP (modułowość itp.), Ułatwiają tworzenie rzeczy takich jak biblioteki. Istnieje wiele sposobów na ponowne wykorzystanie kodu przez oddzielenie problemów itp. - OOP to jeden, dobry projekt metody to drugi, a właściwy rozkład problemu to jeszcze jeden.
Fishtoaster,

1

Obiekty umożliwiają ponowne wysyłanie kodu, ale jako takie nie jest to najbardziej technika. Myślę, że ponowne użycie kodu jest promowane za pomocą technik związanych z obiektami, takich jak dziedziczenie, polimorfizm, przeciążanie i szablony.


1

Tak, robią to, możliwość rozszerzenia (dziedziczenia) po superklasowej klirensie przyczynia się do ponownego użycia kodu, nie jestem pewien, jak ktokolwiek mógłby argumentować inaczej. Możesz po prostu rozszerzyć klasę i przesłonić jedną metodę, używając reszty z superklasy, jeśli to nie pomaga w ponownym użyciu kodu, to nie wiem, co to jest


0

Jeśli tak, czy dotrzymali obietnicy ponownego wykorzystania kodu? Tak, jeśli programy napisane z myślą o OOP mądrze stosują wzorce projektowe. W przeciwnym razie przeważnie nie. Ale patrząc na popularność dużych, nietrywialnych programów, które systemy Adobe, Google i tym podobne piszą w C ++, Javie lub innych językach OOP, powiedziałbym, że OOP ma przed sobą długą drogę do wycofania. Ten czas będzie o wiele bardziej odpowiedni do zadania tego pytania i może pomóc w przygotowaniu gruntu pod nowy paradygmat.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.