Co byś zrobił, gdyby Twój klient nie wymagał programowania obiektowego?

31

Piszę program do symulacji aktywności mrówek w siatce (PDF). Mrówka może się przemieszczać, podnosić i upuszczać.

Problem polega na tym, że działanie mrówek i położenia każdej mrówki można łatwo śledzić za pomocą atrybutów klasy (i możemy łatwo stworzyć wiele instancji takich mrówek), mój klient powiedział, że ponieważ ma doświadczenie w programowaniu funkcjonalnym, chciałby symulacja, którą należy wykonać przy użyciu programowania funkcjonalnego.

Żeby było jasne, oryginalne słowa od klienta to tylko „brak klasy”, ale nie „programowanie funkcjonalne”. Zakładam więc, że nie chodzi o programowanie funkcjonalne i mogę to zrobić koniecznie. Ponadto nie mam wcześniejszego doświadczenia w programowaniu funkcjonalnym.

Myślę jednak, że warto skupić się na tym pytaniu, szczególnie na wymogu programowania funkcjonalnego, niż po prostu „zrób to koniecznie”.

Jak poradziłbyś sobie z tą sytuacją? Czy próbowałbyś przekonać swojego klienta, że ​​programowanie obiektowe jest znacznie bardziej przejrzyste, postarać się postępować zgodnie z jego wymaganiami i dać mu kod niskiej jakości, czy zrobić coś innego?

user8
źródło
9
Jedną rzeczą, która może zmienić jego zdanie, jest to, że koszt tego jest wyższy (jeśli jesteś biegły w językach OO niż w funkcjonalnym języku programowania).
Holger
Ciekawe może być porównanie kodu symulacji Richa Hickeya ( gist.github.com/1093917 ) - w Clojure jest to w zasadzie funkcjonalne, chociaż symulacja została zaprojektowana głównie w celu zademonstrowania zastosowania STM.
mikera
13
Komentatorzy: Nie zostawiaj odpowiedzi tutaj w komentarzach. Napisz własną odpowiedź. Komentarze nie są miejscem do dyskusji na temat różnych możliwych odpowiedzi na pytanie: albo przedstaw sugestię jako odpowiedź, albo zabierz ją na czat, aby ją najpierw opracować.
6
Chcę tylko upewnić się, że widziałeś punkt N3dst4, że „programowanie funkcjonalne” jest szczególną dyscypliną programistyczną. Programowanie, które nie jest obiektowe, jest zwykle określane jako „programowanie proceduralne”.
DJClayworth
1
Jak myślisz, dlaczego implementacja obiektowa byłaby „znacznie czystsza”? Najprawdopodobniej będzie znacznie mniej czytelny niż właściwe rozwiązanie funkcjonalne.
SK-logic

Odpowiedzi:

201

Kod zorientowany obiektowo nie jest z definicji czyszczący, a odwrotnie, kod inny niż OO nie jest z definicji gburowaty. Chociaż wydaje się, że istnieje dość oczywiste mapowanie obiektowe na ten konkretny problem, sugerowałbym, aby mimo to spróbować funkcjonalnego podejścia do programowania. Daj z siebie wszystko, spróbuj rozwiązać problem w najlepszym funkcjonalnym stylu programowania, który możesz zdobyć, a możesz po prostu nauczyć się czegoś, czego się nie spodziewałeś.

Joris Timmermans
źródło
83
+1 za „możesz po prostu nauczyć się czegoś, czego się nie spodziewałeś”!
Kenneth
2
Ponadto programowanie zorientowane na dane zapewnia doskonałą wydajność, ponieważ jest przyjazne dla pamięci podręcznej i jest lepiej zaimplementowane w zestawach funkcji przetwarzających bloki danych. Wydaje się idealny do rozwiązania problemu, nad którym pracujesz. Nie wiem, jak to się ma do programowania funkcjonalnego, ale sądzę, że to pomaga bardziej niż boli.
Klaim
8
+1 za „możesz po prostu nauczyć się czegoś, czego się nie spodziewałeś!”, ALE: Jeśli OP nie ma dużego doświadczenia w programowaniu funkcjonalnym, a klient oczekuje dobrego i taniego rozwiązania, ryzykowne byłoby zanurzenie się w nowy sposób rozwiązywania problemów.
mort
3
@mort - Klient w tym przypadku chce czegoś szczególnego, wygląda na to, że wie wystarczająco, aby wiedzieć, czego chce, więc jeśli wynajmowana osoba nie może tego zrobić, to jego problem. Wydaje mi się, że to, co mówię, to fakt, że klient chce czegoś „dobrego i taniego” i mówię, że wynajął niewłaściwą osobę, która nie może tego zapewnić, z winy klienta, a nie winy autora, że ​​nie wie, jak zapewnić tanią i dobre funkcjonalne rozwiązanie programistyczne dla tego problemu. Jeden z nich jest wart autor stara się dostarczyć to, czego chce klient, ponieważ nie ma technicznego powodu, aby tego nie robić.
Ramhound
2
Nigdzie w pytaniu OP nie wypowiedziało słowa „dobry i tani”. Pragnienie może być „szybkie i dobre” (spośród trzech: szybkie, dobre, tanie). Wszystko to jest bez znaczenia, bez wskazówek OP, ponieważ „Specyfikacje” mówią „Użyj programowania funkcjonalnego”.
WernerCD
68

Wspominasz, że klient zwykł programować w funkcjonalnym języku, być może ma powód, dla którego wymaga pisania kodu w funkcjonalnym stylu. Powinieneś zapytać go dlaczego .

Może zamierza zachować kod i zachować go później.

Co więcej, nie sądzę, że dwie opcje to albo zrobienie tego w stylu OO, albo napisanie kiepskiego kodu, jak wspomniałeś. Na pewno pisanie kodu funkcjonalnego w takim przykładzie może być trudniejsze, szczególnie jeśli masz doświadczenie w językach zorientowanych obiektowo, ale jeśli klient jest gotów poczekać trochę dłużej, abyś nauczył się funkcjonalnego stylu, to nie byłoby boli go o to zapytać.

Zapytałbym go, dlaczego chce kodu w funkcjonalnym stylu, a jeśli czas nie jest tak wielkim problemem, poprosiłbym o kilka dodatkowych dni, aby przyzwyczaić się do programowania funkcjonalnego. (hurra za zarabianie na nauce!)

Jeśli wszystko inne zawiedzie, wyjaśnij, że zajęłoby ci to znacznie mniej czasu, aby zrobić to w stylu OO.

Thanos Papathanasiou
źródło
@downvoter czy mógłbyś przekazać jakieś uwagi?
Thanos Papathanasiou
3
Rozumiem, że notacja tl; dr jest warta pochwały, dla niektórych
Independent
1
Czy jest coś w FAQ lub na stronach pomocy, gdziekolwiek upomina się o użycie „tl; dr”? A może to tylko nieuczciwi użytkownicy, którzy tego nie lubią? Wydaje mi się, że dodanie zwięzłego streszczenia odpowiedzi może być tylko dobrą rzeczą, więc nie wyobrażam sobie, dlaczego byłoby to uważane za warte uwagi.
Ben Lee
1
@Bratch Myślałem, że notacja tl; dr była dla użytkownika próbującego odczytać moją odpowiedź. Oznacza to, że nawet jeśli pominiesz całą resztę, jeśli tylko to przeczytasz, otrzymasz sedno odpowiedzi. Co masz na myśli przez to, co mówisz?
Thanos Papathanasiou
1
Niektórzy z nas, starzy ludzie, nie mają pojęcia, co znaczy tl; dr (sprawdziłem to, ale dlaczego ktoś miałby używać takich tajemniczych bzdur?)
HLGEM,
55

Czy zdajesz sobie sprawę, że programowanie funkcjonalne nie oznacza tylko „programowania bez klas”?

Zobacz pełny artykuł na ten temat w Wikipedii , ale w skrócie ...

W informatyce programowanie funkcjonalne jest paradygmatem programowania, który traktuje obliczenia jako ocenę funkcji matematycznych i unika stanu i zmiennych danych. Podkreśla zastosowanie funkcji, w przeciwieństwie do imperatywnego stylu programowania, który podkreśla zmiany stanu.

Programowanie funkcjonalne jest paradygmatem programowania, podobnie jak OO jest paradygmatem programowania.

Jeśli twoje tło jest w OO, to mogę zobaczyć, jak chcesz, aby wszystkie twoje mrówki były obiektami. Z drugiej strony, jeśli symulujesz farmę mrówek z milionami mrówek, OO i przekazywanie wiadomości mogą stać się nieefektywne.

Na szczęście dla Ciebie Python ma doskonałe narzędzia do programowania funkcjonalnego (najważniejsze jest to, że funkcje są obiektami najwyższej klasy).

Programowanie funkcjonalne Pythona HOWTO

N3dst4
źródło
+1 za ukrywanie tego. Naprawdę należy to wyjaśnić w pytaniu.
Bratch
Czy wiesz, że możesz mieć języki OO i funkcjonalne? Są to dwie zasady organizacyjne, które w rzeczywistości są do siebie w dużej mierze ortogonalne. Wprawdzie wiele języków OO jest również strukturalnymi językami imperatywnymi, ale nie ma teoretycznych podstaw do ich silnego połączenia.
Donal Fellows
@DonalFellows Oczywiście, to dobrze, że te dwa wcale się nie wykluczają. Python (ponieważ pytanie było pierwotnie oznaczone Python) jest imperatywny, obiektowy i funkcjonalny, w zależności od tego, gdzie stoisz, kiedy na niego patrzysz. I gdzie indziej na tej stronie ktoś wspomina OCaml, który jest OO i funkcjonalny.
N3dst4
22

Wyjaśnij swojemu klientowi, że jeśli chce programowania funkcjonalnego, powinien zatrudnić kogoś, kto się w tym specjalizuje. Programowanie funkcjonalne różni się bardzo od OOP i pomylisz się, jeśli uważasz, że możesz go łatwo odebrać i dostarczyć kompleksowe rozwiązanie wysokiej jakości.

KaptajnKold
źródło
Zgodzić się. Jest to po prostu zdrowy rozsądek.
Mister Smith
1
Problem polega na tym, że z biznesowego punktu widzenia nie zawsze łatwo jest przyznać klientowi brak wiedzy („Zamiast tego powinieneś zatrudnić kogoś znającego programowanie funkcjonalne”). Łatwiej jest twierdzić, że OOP jest lepszy, po prostu dlatego, że go znasz. Mniej uczciwy , ale łatwiejszy.
Andres F.,
@Andres F: Radzenie sobie z nowym językiem (i paradygmatem) wcale nie jest łatwe. Wcześniej czy później klient musi ponownie rozważyć problem. Lepiej wkrótce niż później.
Mister Smith
4
@Mister Smith: W pełni się z tobą zgadzam. Mówię tylko, że ten rodzaj uczciwości ze strony dostawcy (tj. Programisty) nie zawsze nadchodzi. Zasadniczo mówisz klientowi, aby zatrudnił kogoś innego, co na całym świecie ma sens, ale jest bolesne.
Andres F.,
13

Istnieje powszechne błędne przekonanie, że „OO” jest całkowicie sprzeczne z „funkcjonalnym”. Te rzeczy mogą iść w parze bardzo dobrze. W twoim przykładzie „Ant” może być modelowany jako abstrakcyjny typ danych, który można łatwo zaimplementować za pomocą klas i obiektów. Przejścia między stanami „Ant” można naturalnie modelować za pomocą funkcji, co doprowadzi cię do funkcjonalnego podejścia, o ile klasa „Ant” jest niezmiennym typem.

I pamiętaj, że „obiekty” mogą być zamienione przez funkcjonalną koncepcję zamknięcia, ponieważ przedmioty są zamknięciami biednego człowieka, przedmioty biednego człowieka są… ;-):

https://stackoverflow.com/questions/2497801/closures-are-poor-mans-objects-and-vice-versa-what-does-this-mean

https://stackoverflow.com/questions/501023/closures-and-objects

Doc Doc Brown
źródło
+1 Programowanie funkcjonalne i OOP to pojęcia ortogonalne. Spójrz na OCaml, Scala, Clojure, python dla języków, które mogą obsługiwać oba.
rds
Te dwa linki są warte wzięcia udziału w głosowaniu ...
Wayne Werner
8

Po rozmowie z klientem, jeśli nadal chce to po swojemu, albo wykonujesz profesjonalną robotę, a jeśli nie możesz, albo nie podpisujesz kontraktu, albo znajdujesz rozwiązanie.

Tworzenie „gównianego kodu” tylko dlatego, że się nie zgadzasz, byłoby wysoce nieprofesjonalne.

Jaydee
źródło
8
  1. Dlaczego wszyscy zakładamy, że klient zna różnicę między programowaniem funkcjonalnym a imperatywnym? Wiele osób nie zna nazw ani specyfiki paradygmatów programowania innych niż OO i chętnie zamienia terminy takie jak „proceduralne”, „imperatywne” i „funkcjonalne”.

  2. Nie chodź tak, jak mówią ci inni, chyba że uważasz, że powinieneś iść tą drogą. Dlatego jeśli nie uważasz, że programowanie funkcjonalne jest odpowiednie, nie nastawiaj się na porażkę lub podejmuj się projektu bez entuzjazmu.

  3. Jeśli klient pisze spec następnie wdrożyć spec, inaczej piszesz spec i realizować swoje spec.

  4. Najlepszą strategią wpływania na decyzje klientów jest uczynienie niepożądanej opcji znacznie droższą. Działa za każdym razem.

  5. Jeśli jesteś ekspertem (w stosunku do klienta), powinieneś być w stanie ich przekonać.

  6. Aby naprawdę wiedzieć, czy klient ma rację, musisz zdobyć więcej doświadczenia z programowaniem funkcjonalnym, abyś mógł go zestrzelić z pewnością lub uświadomić sobie, że twoje nastawienie do OO wynika z twojego braku doświadczenia.

  7. Dlaczego nie zrobić tego w obie strony, pozwól klientowi zobaczyć obie implementacje i zdecydować, które łatwiej utrzymać. Po prostu uwzględnij to wszystko w swoich szacunkach projektu, abyś mógł cieszyć się krzywą uczenia się podczas zarabiania.

Sam
źródło
+1 za „Dlaczego wszyscy zakładamy, że klient zna różnicę między programowaniem funkcjonalnym a imperatywnym?”. Klient może oznaczać coś takiego: „Nie chcę, aby było powtarzalne, więc podziel wszystko na funkcje”, co dla programistów jest rozsądne. Klient może nie myśleć, że to zdrowy rozsądek, więc mówi ci.
AlexWebr
1
+1, w rzeczywistości klient nie ma pojęcia, czym jest programowanie funkcjonalne, albo jest napędzany najnowszymi modnymi słowami, albo dlatego, że zrobił to dwadzieścia lat temu i nadal uważa się za techniczny.
Anonimowy Wpisz
5

Zanim przejdę dalej, upewnię się, że oboje mówicie o tym samym. Możesz zapytać go, kiedy oprogramowanie jest dla niego „obiektowe”. Sine powiedział, że to nie jest jego główna wiedza, być może ma on wypaczony pomysł.

Na przykład wiele osób mogłoby rozważyć

class C {
public:
  C();
  void f( int );
  void g();
};

być klasycznym podejściem obiektowym, ale

struct C;
void construct( C ** );
void f( C *obj, int arg);
void g( C *obj );

nie (nawet jeśli oba są w równym stopniu zorientowane obiektowo, o ile chodzi o klasyczne dane wraz z funkcjami, które na nich działają).

Frerich Raabe
źródło
2
Po co spierać się o dokładne znaczenie OOP? Lepiej byłoby zapytać, dlaczego klient uważa, że ​​jego symulacja lepiej nadaje się do programowania funkcjonalnego. Klient może mieć rację ... Poważnie wątpię , że „funkcjonalny” miał na myśli twój drugi przykład w C lub że mylił „funkcjonalny” z „imperatywnym”.
Andres F.,
@Andres F .: Nie twierdziłem, że przez „funkcjonalny” miał na myśli mój drugi przykład C. Właśnie wskazałem, że niektórzy uważają, że to OOP, podczas gdy inni nie. Dlatego przed rozpoczęciem kłótni dobrze byłoby uniknąć nieporozumień. Może po pierwsze nie ma zgody. Być może szef, ponieważ powiedział, że nie jest zaznajomiony z samym OOP, zakłada, że ​​OOP ma pewne właściwości (tak jak OP najwyraźniej zakładał, że programowanie funkcjonalne ma pewne właściwości).
Frerich Raabe
Ściśle mówiąc, nie uważałbym tego drugiego za OOP, ponieważ wywołanie metody / wysłanie wiadomości nie jest kierowane przez obiekt. To kluczowa cecha OOP.
Donal Fellows
5

Czy próbowałbyś przekonać swojego klienta, że ​​programowanie obiektowe jest o wiele czystsze?

Myślę, że musisz się lepiej uczyć paradygmatów programowania. Obiektowy kod programowany niekoniecznie jest czystszy, aw rzeczywistości nie ma uniwersalnego zastosowania. Ponadto dobry obiektowy programista wie, jak wykonać dobrą pracę za pomocą proceduralnych / modułowych (w paradygmacie funkcjonalnym i deklaratywnym jest to nieco trudniejsze, ale dobry programista nie powinien być zbyt trudny do przybycia - poprzez czytanie i dedukcję - do akceptowalnego rozwiązania FP / deklaratywnego).

Prawie nigdy nie możesz, powtarzam, prawie nie możesz dobrze zrozumieć, kiedy i jak korzystać z Object Orientation, bez dobrego zrozumienia programowania proceduralnego i modułowego. OO to znacznie więcej niż tylko deklarowanie klas i hierarchii dziedziczenia.

A może postarasz się postępować zgodnie z tym, czego on potrzebuje i dać mu gówniany kod?

Jeśli nie możesz napisać dobrego kodu proceduralnie, wątpię, czy możesz napisać dobry kod w sposób obiektowy. Kropka. Nie próbuję tutaj osądzać, ale należy to potwierdzić.

Orientacja obiektowa jest rozszerzeniem programowania proceduralnego i modułowego. Orientacja obiektowa zapewnia po prostu narzędzia, które przy odpowiednim zastosowaniu dają lepsze mechanizmy radzenia sobie z problemami enkapsulacji, łączenia, spójności i ponownego użycia / rozszerzalności kodu.

Ale wszystkie te problemy nie są nieodłączne i specyficzne dla OO. Istnieją w kodzie proceduralnym / modułowym (i w innych paradygmatach w tej sprawie). Jest to rodzaj problemów ze złożonością, które w swej istocie są niezależne od paradygmatów. Jeśli nie poradzisz sobie z nimi bez kleju OO, to jest mało prawdopodobne, że poradzisz sobie z nimi.

=========

Wracając do pierwotnego pytania, czy spróbować przekonać klienta. To zależy. Jak powiedział Sean McMillan, jeśli klient po prostu próbuje mikro-zarządzać pracami rozwojowymi nad jakimś programem (czytanie, polityka biurowa), odejdź. Ludzie, którzy dokonują tego sabotażu, projektują, aby obwiniać kogoś innego lub realizować konkretny program. Nie chcesz się w to angażować.

OTH, mogą istnieć inne powody takiego wymogu. Wiele sklepów osadzonych, zarówno dobrych, jak i złych, decyduje się na wiele ograniczeń dotyczących tego, co można zrobić w C ++ (na przykład bez metod wirtualnych, bez wyjątków). Czasami robi się to w sposób szarpiący kolana. W innych przypadkach istnieją uzasadnione przyczyny techniczne.

Musisz więc zrozumieć, dlaczego klient chce unikać kodu OO. A jeśli możesz przypuszczać, że nie ma programu politycznego (bez czerwonych flag), powinieneś zrobić coś profesjonalnego, czyli po prostu zrobić kod proceduralny / modułowy i zrobić dobrą robotę.

Naprawdę nie ma usprawiedliwienia dla dostarczania kiepskiego kodu, niezależnie od paradygmatu programowania. Jeśli nie możesz stworzyć akceptowalnego kodu za pomocą jednego paradygmatu, z całą pewnością nie możesz stworzyć akceptowalnego kodu w ogóle.

luis.espinal
źródło
3

Mieszacie struktury danych i programowanie obiektowe (powszechne zamieszanie w tym zainfekowanym świecie OO)

Jeśli wszystko, co musisz zrobić, to „śledzić atrybuty danych” w strukturze danych i modyfikować je, to prawie każdy język utworzony po latach 70. będzie miał dla niego dobre wsparcie, OO lub nie.

To, co łatwiej zrobić w OO, to szorstka mucha

  • Dziedziczenie oparte na klasach (łatwo jest stworzyć nową klasę, która udaje starą)
  • Polimorfizm oparty na klasach (później łatwo jest dodać nowe rodzaje mrówek do symulacji)

Jeśli nie potrzebujesz jednej z nich, zasadniczo każdy paradygmat programowania powinien rozwiązać ten problem bez zbyt wielu problemów.

hugomg
źródło
Dodałbym, że każdy funkcjonalny język programowania z obsługą polimorfizmu powinien dość łatwo pisać styl zorientowany obiektowo lub pseudoobiektywnie, który pozwala łatwo dodawać nowe typy mrówek.
Marcin
@Marcin: to prawda, że ​​współczesne języki FP są dość potężne. Chciałem tylko zwrócić uwagę na rozróżnienie między strukturami danych / ADT a OO
hugomg,
Ale OO to tak naprawdę tylko ADT i obiektowa metoda wysyłania. Wszystko inne opiera się na tym. (Cóż, często jedyną kontrolą obiektu nad wysyłką jest typ obiektu, ale jest to udoskonalenie.)
Donal Fellows
3

mój klient powiedział, że ponieważ ma doświadczenie w programowaniu funkcjonalnym, chciałby, aby symulacja została wykonana przy użyciu programowania funkcjonalnego.

(Jest to kolejny przykład pomylenia problemu społecznego z zagadnieniem technicznym / projektowym).

Istnieją dwie możliwości:

  1. Twój klient spodziewa się, że będzie mógł pobrać napisany przez Ciebie kod i zaadaptować go lub zachować samodzielnie po zakończeniu pisania. Jeśli tak, to powinieneś dowiedzieć się znacznie więcej o „stylu domu” - funkcjonalne vs OO to tylko wierzchołek góry lodowej. Musisz albo ograniczyć się do stylu programowania, który rozumie twój klient, albo musisz nauczyć swojego klienta stylu, który preferujesz. (Raz poproszono mnie o zbudowanie aplikacji internetowej z CGI, bez użycia szablonów lub bibliotek, ponieważ klient może chcieć wprowadzić zmiany).

  2. Twój klient próbuje kontrolować rozwój z powodu jakiegoś programu. To pełna szaleństwa torba, z którą nie chcesz mieć nic wspólnego. Jeśli naprawdę dostarczasz oprogramowanie „pod klucz”, klient nie powinien się przejmować, czy składa się on z chomików poruszających się na kołach, o ile działa niezawodnie. Pozwolenie na mikrozarządzanie w ten sposób wymaga jedynie bólu.

To Ty decydujesz, w jakiej jesteś sytuacji, i postępujesz zgodnie z nią.

Sean McMillan
źródło
3

Umm ... czy tylko ja tutaj myślę „to oczywiście praca testowa / zadanie”? .

Po pierwsze - samo zadanie ma charakter „akademicki” (symuluje aspekt zachowania mrówek).

Po drugie - żądanie implementacji wymagań przy użyciu (lub unikania) bardzo specyficznego paradygmatu programistycznego pachnie „klientem”, który może czytać kod i dokonywać takich twierdzeń.

Jeśli tak jest, lepiej rób to, co jest od ciebie wymagane - będzie to raczej przyjemne doświadczenie edukacyjne, a jeśli możesz to zrobić, nauczysz się wiele podczas tego procesu ...

Jeśli tak nie jest, powinieneś zapytać siebie i / lub klienta o uzasadnienie zlecenia. Jeśli rozumowanie jest solidne, zrób to - nauczysz się i będziesz lepszy jako programista tego doświadczenia. Kto wie - możesz nauczyć się lubić funkcjonalny styl w stosunku do OO.

Jeśli brakuje wyjaśnienia, wszystkie zakłady są wyłączone. Nie mogę ci zalecić, co robić.

Możesz spróbować niezależnie od wdrożenia wymagań w funkcjonalnym języku / stylu lub możesz grzecznie odrzucić ofertę, jeśli poczujesz coś podejrzanego.

Najważniejsze jest - gdy zrozumiesz motywację stojącą za wymaganiami, właściwy kierunek działania stanie się oczywisty.

EDYCJA: Po przekątnym spojrzeniu na przywoływany plik PDF, opisane tam algorytmy z pewnością wydają się dobrze pasować do funkcjonalnego stylu, a nie do OO

Roland Tepp
źródło
2

Prośba o zastosowanie programowania funkcjonalnego ma kilka dobrych aspektów:

  1. Masz klienta, to zawsze dobry znak
  2. Klient oczekuje, że będziesz bardzo dobry w tym, co robisz. Dlatego pytają o programowanie funkcjonalne. Twoja organizacja sprzedaży wykonuje dobrą robotę lub żądasz bardzo wysokiej ceny za swoje usługi.
  3. Organizacja klienta ma ludzi, którzy wiedzą, że programowanie funkcjonalne jest dobrą rzeczą i będzie duże w przyszłości

Ale są też niepokojące objawy:

  1. Wydaje się, że nie jesteś przygotowany na wdrożenie go w programowaniu funkcjonalnym. Jesteś już trochę przestarzały w swoich umiejętnościach i nie możesz nadążyć za zmianami.
  2. Albo klient oczekuje, że będziesz lepszym programistą niż w rzeczywistości. Oznacza to, że może być konieczne obniżenie ich wymagań do momentu, aż będzie to możliwe.
tp1
źródło
-1 dla domyślnego założenia, że ​​FP jest lepszy niż OOP.
Russell Borogove
@ tp1 1) Zakładasz, że klient jest technicznie mądrzejszy od programisty, co nie jest prawdą, ponieważ klient jest po prostu tym klientem. 2) FP jest starszy niż OOP i chociaż ostatnio jest dużo prasy, nie ma nic złego w OOP i nie musisz zapominać o użyciu FP 3) Najgorsze jest to, że założenie, że FP jest lepsze i używa FP czyni cię lepszym programistą, jest prawdą tylko w indywidualnych przypadkach, w tym przypadku wydaje się to nieprawdą.
Joe Tyman
@Joe Tyman: Cóż, należy założyć, że ludzie nie są głupi, w przeciwnym razie klienci znikną natychmiast. Nie próbowałem powiedzieć, że oop jest zły lub gorszy, ale zamiast tego założenie, że funkcjonalność może być nieuzasadnionym wymogiem w tej sytuacji - być może klient nie zna umiejętności programistów lub, co gorsza, próbuje zmusić programistów do zmiany technologii.
tp1,
@Joe Tyman: Ponadto najgorszym scenariuszem, jaki miałem na myśli, było to, że klienci naprawdę potrzebują ludzi, którzy mogą wykonywać zaawansowane programowanie funkcjonalne, takie jak teoria kategorii, i starają się znaleźć zespół, który może to zrobić - dlatego prośba bo mogą być nierozsądne.
tp1,
1

Oparcie się na powyższych odpowiedziach, że być może OO nie jest najlepszym rozwiązaniem, w którym to przypadku klient może mieć rację.

Spójrz na AI Challenge, które modeluje niektóre zachowania wyszczególnione w pytaniu tutaj http://aichallenge.org, a następnie zapoznaj się z różnorodnością pakietów startowych - http://aichallenge.org/starter_packages.php/ most są języki, których nie umieszczałbym w paradygmacie OO.

Łukasza
źródło
1

Nie napisałeś nic o języku programowania, który jest prawdopodobnie najważniejszą rzeczą. Różnica między OOP a programowaniem funkcjonalnym polega nie tylko na sposobie organizacji kodu, ale także na języku. W przypadku wysokiej współbieżności używany jest funkcjonalny język Erlang, który ma bardzo dużą przewagę nad np. Javą (jest używany np. Przez czat na Facebooku). Rozwiązanie OOP może po prostu zawieść z powodu problemów z wydajnością.

Tutaj klientem jest uniwersytet, więc język to nie tylko kwestia wydajności / konfiguracji, kod może być również wykorzystywany do pracy dydaktycznej ze studentami lub do własnych badań. Tak więc „przekonanie” klienta do wyboru innego paradygmatu nie ma moim zdaniem zastosowania tutaj. Możesz albo poradzić sobie z zadaniem, albo nie możesz (i dlatego nie powinieneś brać tego projektu).

Żeglarz dunajski
źródło
0

Klient mówi „skacz”, twoja odpowiedź brzmi: __ _ ?

Dla mnie postaram się przekonać, czy ma to sens (nowy projekt), ale mam też klienta z 10-letnią aplikacją VB6, którą czasami aktualizuję ... nie zamierzam ich przekonywać

bumerang
źródło
technicznie rzecz biorąc, aplikacja VB6 jest w porządku, to prawie OO, a jeśli działa dobrze w obecnym systemie operacyjnym, dlaczego „uaktualnić” do .NET. To po prostu nie ma sensu, chyba że chcesz skorzystać z nowej funkcjonalności.
Anonimowy Wpisz
Tak, ale czy próbowałeś ostatnio używać vb6? to bardzo bolesne;)
boomhauer
Tak. Dużo tego używamy do utrzymywania istniejących aplikacji, które nie otrzymały jeszcze budżetu na aktualizację Java lub .net. Jest bolesny (w porównaniu do nowoczesnego IDE), ale także względny. Jak każdy język (w tym skrypty), kiedy już dobrze sobie z tym radzisz, twoja definicja bólu staje się bardziej subiektywna.
Anonimowy typ
0

„Zbadaj” trochę swojego klienta (w sposób niekonfrontacyjny):

Czy klient faktycznie zna różnicę między OOP a programowaniem funkcjonalnym? Czy obawy / prośby klienta są uzasadnione?

Jeśli „Tak”: Jeśli masz kwalifikacje, rób, co chcesz i zabierz swoje pieniądze. Jeśli nie masz kwalifikacji, powiedz im o tym i pozwól im zdecydować, co robić.

W przeciwnym razie: cześć, ogon!

Wektor
źródło
0
double dist(Point p1, Point p2) 
{
  //return distance
}

Ta funkcja działa, o ile nie odczytuje / nie zapisuje niczego poza funkcją. Gdyby funkcja dotknęła zmiennej klasy, przestałaby być „funkcjonalna”. Zaletą funkcjonalnego stylu jest to, że nie ma już błędów związanych ze zmianą lub nieprawidłowym stanem. Duża liczba funkcji to tylko formuły matematyczne. To funkcjonalne programowanie w pigułce.

BTW możesz łączyć funkcjonalny styl w projektowaniu obiektowym lub zorientowanym. Na przykład dwie zmienne „Punkt” to obiekty ze stanem. A funkcja nadal działa! Tak !!

Lord Tydus
źródło