W jakim stopniu architektura oprogramowania zależy od języka?

Ucząc się o architekturze oprogramowania i wzorcach projektowych zauważyłem, że w większości przypadków wyjaśniono niektóre cechy języka i specyfikę projektu.

Np. Praktycznie każdy artykuł lub książka na ten temat zilustruje pomysły za pomocą klas i interfejsów. Wszystko, co można łatwo znaleźć na ten temat, wspomina o obiektach i koncepcjach OOP.

Co jeśli język, w którym napisany jest system, w ogóle nie ma takich pojęć? Np. Co się stanie, jeśli użyję języka Python lub węzła, które są dynamicznie wpisywane i nie mają pojęcia interfejsu? Co się stanie, jeśli użyję TypeScript, gdy interfejs jest efemeryczną konstrukcją, która nie istnieje w środowisku wykonawczym? Co jeśli próbuję objąć programowanie funkcjonalne? Czy powinienem zignorować np. SOLID i poszukać innych pojęć odpowiednich dla mojego języka?

Jeśli tak, jakie to są? Niestety wszystkie dobrze przyjęte paradygmaty (o ile mi wiadomo) w pewien sposób odnoszą się do pojęć i typów OOP. Jeśli nie, jakie zasady powinienem stosować, dostosowując ogólne zasady architektury i projektowania do mojego konkretnego języka i przypadku użycia?

Jak ogólnie opisałbyś zależność między architekturą a językiem?

Architektura oprogramowania jest bardzo podobna do architektury domu lub mostu. Most musi utrzymywać ciężar samego siebie i przejeżdżających przez niego pojazdów lub przechodzących przez niego ludzi. Musi wytrzymać pogodę. Materiały użyte do jego zbudowania muszą być zarówno mocne, jak i stosunkowo lekkie.

Istnieje wiele materiałów, których można użyć do budowy domu. Możesz użyć cegły lub sztukaterii. Możesz użyć belek drewnianych lub metalowych. Każdy materiał ma swoje własne cechy pod względem masy, wytrzymałości i tak dalej. Wszystkie te cechy wpływają na architekturę.

W ten sam sposób używany język programowania wpływa na sposób budowania architektury. Twoja architektura będzie wyglądać inaczej w języku programowania, który ma klasy takie jak C ++, niż w języku programowania, który nie ma, podobnie jak C.

Zasady SOLID dotyczą głównie języków obiektowych (tj. Języków posiadających klasy).

Architektura zależy od możliwości osiągnięcia jej celów. Wybór języka może ograniczyć możliwości. Każdy kompletny język Turinga ma możliwość wykonania dowolnego zadania programistycznego. Po tym punkcie chodzi o to, jak czytelny dla człowieka język pozwala na rozwiązanie.

Wiele schematów architektury oprogramowania wymaga usunięcia całej wiedzy na temat wyboru technologii z podstawowych reguł biznesowych domeny. Jedynym technicznym wyborem, którego nigdy nie możesz usunąć z rdzenia, jest język, w którym chcesz go wyrazić.

Kiedy książki o architekturze trzymają się informacji o swoich celach, język nie ma znaczenia, o ile jest w stanie osiągnąć cel. Kiedy w książkach dowiesz się, jak osiągnąć te cele, język zacznie mieć znaczenie.

Architektura jako termin ma bardzo konkretne znaczenie, które jest bardzo związane z architekturą w świecie fizycznym, a jej sednem jest sztuka i praktyka budowania rzeczy, to, jak rzeczy są tworzone i składane. Biorąc to pod uwagę, gdy architektura jest dobrze wykonana, myślę, że język jest ściśle powiązany z architekturą, podobnie jak dobrze zaprojektowany budynek powinien być ściśle poinformowany przez materiał, z którego jest zbudowany.

W oprogramowaniu wybory architektoniczne powinny być dokonywane w sposób zgodny z właściwościami języka. Jeśli budujesz system z językiem zorientowanym obiektowo, to spodziewałbym się, że architektura systemu również będzie zorientowana obiektowo. Jeśli budujesz system z funkcjonalnym językiem, oczekiwałbym, że architektura tego systemu również będzie funkcjonalna.

Ma sens?

Na początek powiedziałbym, że nawet język, w którym myślisz, ma głęboki wpływ na to, co możesz sobie wyobrazić. Jest powód, dla którego PASCAL został stworzony przez Niklausa Wirtha, a C przez Briana Kernighana i Dennisa Ritchie.

Na wyższym poziomie umiejętność wyrażania pewnych pojęć (i brak innych) skieruje twoją myśl i sprawi, że dojdziesz do pewnych rozwiązań, które niekoniecznie byłyby tą samą inną osobą, z innym pochodzeniem, wymyślone.

Wreszcie, wszystkie wspomniane pojęcia można zaimplementować w dowolnym języku ogólnego przeznaczenia. Tyle, że mogą nie mieć wsparcia składniowego, a implementacja może być uciążliwa. Możesz napisać zorientowany obiektowo kod asemblera x86, jeśli jesteś wystarczająco zaangażowany (lub wystarczająco szalony), tak jak możesz to zrobić w C. W rzeczywistości, pierwsze implementacje C ++ były preprocesorami, które skompilowały Twój kod C ++ w C (i zniekształcone nazwy symboli zostały wykonane debugowanie o wiele więcej zabawy).