Czy warto szukać alternatywy dla Object Oriented Programming OOP?

Mam do naprawy projekt w kodzie po poprzednim programiście.
Z Event Stormingu, który przeprowadziłem z biznesem wyszedł mi system, będący archetypem w wzorcu pipe and filters
Klasyczny przykład, gdzie mamy wejście w module i jakieś wyjście. Na wejściu dane + konfiguracja, który jest zmienna.
Trochę anty-coruption layer do systemów zewnętrznych.

Na początku wchodzą jakieś dane wraz z konfiguracją (zmienną) i na każdym kolejnym etapie są przetwarzane.
System nie działa cały czas produkcyjnie, lecz jest uruchamiany przez użytkownika z konsoli. Użytkownik zna podstawy Pythona i może sobie coś w programie i konfiguracji zmienić.

Całość napisana w Pythonie obiektowo. Są także moduły w C/C++.
Z racji wydajności są "wrappery" do modułów w C/C++ lecz i tak uruchamiane z poziomu Pythona.

Biznes życzy sobie bardzo dużej elastyczności w konfiguracji jest chęć na przepisanie modułów. Celem jest wprowadzenie elastyczności konfiguracji poszczególnych modułów.

Myślałem o modelowaniu systemu funkcyjnie, lecz totalnie nie zauważam z tego korzyści. System nie produkcji, która może się wywalić - w tym przypadku nic się nie stanie.
Z analizy i przeprowadzonego Domain Driven Design mam już podzielony system na trzy domeny, zrobiłem ubiquitus language i wszystko pięknie.
Więc mam książkowy Event Storming, książkowe Domain Driven Design. Domeny podzielone, ubuquitus language jest więc co może pójść nie tak?

Więc czy jest jakikolwiek sens robienia inaczej niż obiektowo?

Czerwona flaga:

Użytkownik zna podstawy Pythona i może sobie coś w programie i konfiguracji zmienić.

Miejmy nadzieje żę ten użytkownik wie również jak testy odpalić po swoich "usprawnieniach". Modułów w C++ pewnie ciężko mu będzie ruszyć no chyba że ten użytkownik to inny programista.

Biznes życzy sobie bardzo dużej elastyczności w konfiguracji jest chęć na przepisanie modułów.

Kolejna czerwona flaga. Im więcej konfiguracji tym trudniej to przetestować. Liczba przypadków rośnie co najmniej wykładniczo.

co może pójść nie tak?

System może tak zamulać że będzie nieużywany. Brak typów będzie sprawiał że po modyfikacjach może być sporo błędów w runtime'ie.

Na początku piszesz że wyszła Ci architektura "pipes and filters", w sumie to akurat architektura która jak ulał pasuje do programowania funkcyjnego.
Dodatkowo sugeruje to że ważne w tym systemie są dane a nie interakcje/logika. To znów wskazuje na FP które dane stawia w centrum.

Na oko jest to kandydat to pisania pod przetwarzanie strumieniowe aka Kafka Streams lub Akka Streams. Wtedy deklaratywnie zadeklarujesz etapy przetwarzania:

readData ~> validateData ~> askOtherSystemForX   | ~> writeToZ
                      |~> askOtherSystemForY ^|

(W Scali to może być faktyczna składnia).

Oczywiście jeżeli wielowątkowość nie jest ważna, jak również system nie jest krytyczny to nawet jakbyś napisał w NodeJS to i tak by działał. Wiadomo dobry specjalista to nawet i w największym G napisze coś co działa...

Hmm a masz zespół, który ogarnie paradygmat inny niż obiektowy? Jeśli piszą obiektowo to nie, nie przestawia się ;)

Druga sprawa, zrobiłeś jakaś analizę zad i walet oni podejść? Jaka jest największa wada/ryzyko po stronie pipe&filters?

@0xmarcin:

Dodatkowo sugeruje to że ważne w tym systemie są dane a nie interakcje/logika. To znów wskazuje na FP które dane stawia w centrum.

Dlaczego niby FP stawia dane w centrum?
FP pozwala na tworzenie łatwo modyfikowalnego flow, natomiast logika wewnątrz poszczególnych operatorów (zwłaszcza jeśli będą one stanowe) to już trochę trudniejszy kawałek tortu.

Zgadzam się z tym, że można spróbować korzystać z Kafka Streams do tego, natomiast wybór języka chyba zależy od tego jak te dane są przetwarzane i jakie są oczekiwania względem tego.

No to na oko @Marcin Marcin w bagno się pakujesz, rób testy i pisz tak jak najlepiej potrafisz. A i miej na oku niedawny wątek z pozwem nie daj sie zrobić w ... jak jesteś na B2B...

Z drugiej strony mnóstwo osób na UoP robi CVDD czyli CV-driven development na produkcji.
Dwa przypadki z życia.

Pierwszy:

• Mam do zrobienia nowy projekt. Co wybrać, Springa czy Guice?
• A co znasz?
• Springa
• To weź Guice

Drugi:

• Mamy nowy microservice do zrobienia który nie może używać naszego frameworka opartego na Dropwizadzie. Chcecie użyć gołego DropWizarda czy coś nowego? - powiedzał kierownik
• Coś nowego! - odkrzyknął zespół
• A co?
• Spring! Mikronaut! Akka-Http - każdy krzyczał to czym najbardziej się jarał

Czyli niektórzy na twoim miejscu wzięliby to to czym się bardziej jarają lub co bardziej chcą mieć w CV

@KamilAdam: Nie robimy CV Driven Developement

Pytanie dotyczy czy warto warto szukać alternatywy dla Object Oriented Programming?
Ten sam problem mogę zaprogramować zgodnie z Pipe And Filters w Pythonie obiektowo i funkcyjnie. Oba będą działać. Dlaczego miałbym nie wybierać lub wybrać paradygmat obiektowy?

(Jeszcze) nie czytałem, ale byc moze by Ci sie przydalo:
https://www.manning.com/books/data-oriented-programming

Jesli chodzi o architekturę to żadna nie przetrwa jesli uzytkownicy moga sobie gmerać we wszystkim. Daj im API a core zachowaj nienaruszony.
Do API tez jest kilka książek, najłatwiej obronić restowe.

Jesteś juniorem odpowiedzialnym za cały projekt.

To brzmi jakby nie mieli dla ciebie lepszej roboty i wrzucili cie w mniej priorytetowe rzeczy, albo to prosta robota a ty kombinujesz. Ewentualnie firma to żart.

Userem systemu jest programista pythona, który podmienia konfiguracje w locie, a aplikacja nie działa cały czas produkcyjnie.

Brzmi jakbyś robił ACL na ACL by za jakis czas ktos inny pokrył to ACLem.

Zrobiłeś ES po którym ci wyszła już architketura której nie znasz wad i zalet.
Mówisz ze architektura streamowa pasuje, ale styl funkcyjny nie pasuje.

Imo duzo chaosu, cały stos narzędzi do wyboru i kusi by stworzyć cos o czym jest głośno na konferencjach, w tym wypadku to utrudnia prace, jako junior powinieneś nauczyć się najpierw dobrze obsługiwać młotek, by chwycić za super fajna spawarkę.
Programowanie funkcyjne możesz mieszać z OOP.
Tam gdzie trzeba będzie bawić się streamami to użyjesz funkcyjnego z pozostawieniem po sobie opisu (nie musisz dokumentacji) odnośnie działania tego miejsca - mało kto zna ten styl. Gdzie nie jest to potrzebny to czysty OOP domyślnie powinien być dobry - rozczyta go każdy kto przyjdzie po tobie.

Masz zebrane wymagania. Skoro robiłeś ES to pewnie jest tam proces, to teraz stworz scenariusze testowe pod ten proces, możesz to nazywac sobie BDD. Rozpisz specyfikacje. Dodatkowo możesz zrobić diagram dynamiczny np. Sekwencyjny rozświetli ci to bardziej problem tym samym pomoże w doborze rozwiązania.