Jakie były wzorce projektowe ery programowania proceduralnego? [Zamknięte]

Podobne: Jak zrobiono programowanie 20 lat temu?

OOP jest obecnie dość modny, ma swoje korzenie w Simula 67 w latach 60. XX wieku, a później stał się popularny w Smalltalk i C ++ . Mamy DRY, SOLID, wiele książek o wzorach projektowych w świecie obiektowym.

Ale jakie były główne zasady programowania przed przyjęciem całego paradygmatu OOP? A jakie były główne wzorce projektowe?

Byłem programistą Cobol, zanim nauczyłem się Java. Tworzę od ponad 35 lat.

W czasach języków proceduralnych większość przetwarzania odbywała się wsadowo. Cofnij się wystarczająco daleko w historii, a nawet kompilacja programu została wykonana za pomocą talii kart dziurkowanych w partii.

Wbrew twierdzeniom Kiliana Fotha mieliśmy wzorce projektowe w latach 70. i 80. W Cobolu istniał pewien sposób na kodowanie dopasowania / scalania wielu plików. Był pewien sposób na kodowanie dodawania transakcji do pliku głównego (taśmy) w Cobolu. W Cobolu istniał pewien sposób na kodowanie generowania raportów. Dlatego pisarz raportów IBM nigdy tak naprawdę nie zyskał na popularności w wielu sklepach Cobol.

Nastąpiło wczesne zastosowanie zasady DRY. Utwórz wiele akapitów, aby się nie powtarzać. Techniki kodowania strukturalnego zostały opracowane w latach siedemdziesiątych, a Cobol dodał do języka słowa strukturalne (czasowniki) w 1985 roku.

Ogólnie, kiedy pisaliśmy nowy program Cobol, skopiowaliśmy stary program Cobol i zmieniliśmy nazwy, aby chronić niewinnych. Prawie nigdy nie kodowaliśmy programu Cobol z pustej kartki papieru lub pustego ekranu. To duży wzorzec projektowy, gdy możesz kopiować i wklejać całe programy.

Było tak wiele wzorców projektowych Cobola, że ​​programista Cobol potrzebował lat, aby się ich nauczyć. To jeden z powodów, dla których programiści Cobola w większości nadal używają składni z 1985 roku.

„Wzory projektowe” w oprogramowaniu nie istniały w erze, o której mówisz, ponieważ koncepcja nie została wynaleziona. To nie mnie jest niepoważny - to faktycznie jest powód; bycie nazywanym rozpoznawalną nazwą sprawia, że ​​wzorzec projektu jest „wzorzec projektu”, a nie tylko kodem, który ciągle używasz w takiej czy innej formie (np. „fabryka”, a nie „rodzaj klasy statycznej, którą lubię używać, a nie asortyment konstruktorów ”), a sama koncepcja nie jest wyjątkiem.

To powiedziawszy, oczywiście były rzeczy, które spełniały dokładnie taką samą rolę w pracy praktyków, jak obecnie wzorce projektowe. Ale będziesz rozczarowany, gdy usłyszysz o nich: typową „sztuczką guru” były w tamtych czasach rzeczy, które są dla nas dość nudne - np. Pojedynczo połączone listy, pętle kontrolowane przez indeks zwiększany przy każdej iteracji, sprytny „akcesor” „metody, które wydają się nic nie robić, ale dają swobodę w zmianie zdania na temat szczegółów implementacji później.

Zgadza się, rzeczy, które teraz bierzemy za pewnik - które czasami są nawet częścią używanych przez nas języków - były zaawansowanymi (a czasem zazdrośnie strzeżonymi) koncepcjami znanymi tylko bardziej doświadczonym programistom. Są szanse, że prawie wszystko, co nie jest zupełnie trywialne, czego nauczysz się podczas podstawowego kursu programowania, przeszło fazę, w której był to moralny odpowiednik „wzorca projektowego” dla praktyków tamtych czasów. Konstrukcja oprogramowania może jeszcze nie być rygorystyczną dyscypliną inżynieryjną, ale jeśli studiujesz najnowszą technologię lat 50. i 60., nie można zaprzeczyć, że od początku była ogromna .

Poprzedni duży paradygmat polegał na programowaniu strukturalnym . Zamiast UML istniało wiele różnych diagramów (schematy przepływu, diagramy przepływu danych, schematy struktur itp.). Rozwój był głównie odgórny i następował po procesie rozkładu funkcjonalnego. Jednym z podstawowych pomysłów było to, że struktura twojego programu powinna przypominać diament: główny moduł u góry, rozwijający się w moduły sterujące wysokiego poziomu, które wywoływały procedury w modułach niższego poziomu. Te moduły niższego poziomu zbudowane na jeszcze niższych modułach, z których wszystkie (teoretycznie) ostatecznie zbiegły się w kilku podstawowych procedurach We / Wy. Moduły wysokiego poziomu miały zawierać logikę programu, moduły niższego poziomu były bardziej zainteresowane integralnością danych i obsługą błędów.

Ważnymi pojęciami wprowadzonymi w tym czasie były ukrywanie informacji, modułowość oraz wysoka kohezja / niskie sprzężenie. Zobacz prace Dave'a Parnasa, aby znaleźć kilka ważnych artykułów na te tematy. Zobacz także twórczość Larry'ego Constantine'a, Toma DeMarco i Eda Yourdon.

Podejrzewam, że jednym dużym (oprócz samego programowania strukturalnego) była koncepcja przekazania uchwytu - w OO masz obiekt i zawiera on stan i funkcjonalność. Wcześniej przed OO miałbyś mnóstwo niezależnych funkcji i przekazywałeś uchwyt do jakiegoś stanu między nimi - ciasteczka, jeśli chcesz. To dało ci zasady OO bez faktycznego posiadania OO.

Widać to bardzo często w starym kodzie Win32, należy przekazać UCHWYT, który byłby nieprzezroczystym typem reprezentującym stan przydzielony w jądrze systemu Windows. Możesz to zrobić samodzielnie, przekazując wskaźnik do struktury, którą wcześniej przypisałeś jako pierwszy parametr do funkcji działających na tych danych.

Ponieważ nikt jeszcze nie wspomniał o oczywistym: jednym wielkim wzorcem projektowym w erze proceduralnej był Object. Podobnie jak wiele popularnych wzorców projektowych przed (np. Podprogram) i później (np. Iterator), stał się tak popularny, że otrzymał nawet wsparcie językowe.

„Maszyna stanów skończonych” może być liczona jako wzorzec, a moduły FSM zostały napisane (np. Dla protokołów komunikacyjnych) przy użyciu języków sprzed OO.

Popularne były również „procedury obsługi przerwań” i TSR, np. W systemie DOS.

Terminy takie jak „Kod spaghetti” i „Pojedynczy punkt wyjścia” są w rzeczywistości cofnięciami do tamtych czasów. Obecnie nazywamy kod, ale nie lubimy „kodu spaghetti”, ale tak naprawdę jest to odniesienie do kodu powiązanego (źle) z GOTO i JMP.

(Dzisiaj cierpimy na „kod ravioli”, w którym kod jest jak grupa niepowiązanych, ciasno spakowanych klas, podobnie jak talerz ravioli. Jednak niektórzy eksperci OO słusznie pytają: „Ale czy to nie OO powinno to robić wygląda jak?")

„Single Point of Exit” jest dziś frustrującą przeszkodą w refaktoryzacji. Wielu deweloperów, z którymi rozmawiam, nawet o tym nie słyszało i są przerażeni, kiedy to wyjaśniam. Ale w dawnych czasach oznaczało to, że nie wyskakuj nagle z bloku kodu i nie wprowadzaj kodu spaghetti. Przeskocz do przodu na koniec logiki, a następnie z wdziękiem wyjdź.

Rozciągając moją pamięć w przeszłość, wydaje mi się, że pomysł połączenia kodu w procedury był dużym krokiem naprzód. Pomysł, że można spakować procedury w interoperacyjne moduły wielokrotnego użytku, był swego rodzaju Świętym Graalem programowania.

EDYCJA: „Kod samodopasowujący się” był również wzorem stosowanym szczególnie w oryginalnej Doomie. Właśnie tam program nadpisuje instrukcje szybszymi instrukcjami w zależności od jego stanu. Kiedy byłem tykiem na kursie programistycznym w Muzeum Nauki, mój instruktor ostrzegł nas surowo: „Nie pisz kodu modyfikującego sam siebie!”

EDYCJA EDYCJA: Jednak przed Internetem słowo wędrowało znacznie wolniej. Pomysł implementacji algorytmów i struktur danych był znacznie większy. Dzisiaj sortuję cały czas, nawet nie wiedząc, jakiego używam. Ale wtedy musiałeś to sam zakodować. Pamiętam jeden artykuł mówiący o wyzwaniach programistycznych, które kiedyś zajmowały dni, które dzisiaj nokautujemy za pół godziny lub krócej. Tak naprawdę świadome programowanie „algorytmiczne” i „struktura danych” prawdopodobnie znalazłoby się na liście, znacznie bardziej niż dzisiaj.