Zasada abstrakcji (programowanie komputerowe)

W inżynierii oprogramowania i teorii języka programowania zasada abstrakcji (lub zasada abstrakcji ) jest podstawowym powiedzeniem , które ma na celu ograniczenie powielania informacji w programie (zwykle z naciskiem na powielanie kodu ), gdy tylko jest to praktyczne, poprzez wykorzystanie abstrakcji dostarczonych przez język programowania lub biblioteki oprogramowania . Zasada jest czasami podawana jako zalecenie dla programisty, ale czasami jako wymóg języka programowania, zakładając, że rozumie się, dlaczego abstrakcje są pożądane. Pochodzenie zasady jest niepewne; był wielokrotnie wymyślany na nowo, czasem pod inną nazwą, z niewielkimi zmianami.

Czytana jako zalecenia dla programisty, zasada abstrakcji może być uogólniona jako zasada „ nie powtarzaj się ” (DRY), która zaleca unikanie powielania informacji w ogóle, a także unikanie powielania ludzkiego wysiłku związanego z oprogramowaniem proces rozwoju.

Zasada

Jako zalecenie dla programisty, w sformułowaniu Benjamina C. Pierce'a w Types and Programming Languages ​​(2002), zasada abstrakcji brzmi (podkreślenie w oryginale):

Każda istotna funkcjonalność w programie powinna być zaimplementowana tylko w jednym miejscu w kodzie źródłowym. Tam, gdzie podobne funkcje są realizowane przez różne fragmenty kodu, ogólnie korzystne jest połączenie ich w jeden poprzez wyabstrahowanie różnych części.

Jako wymaganie języka programowania, sformułowane przez Davida A. Schmidta w The structure of typed programowania Languages ​​(1994), zasada abstrakcji brzmi:

Można nazwać wyrażenia dowolnej semantycznie znaczącej klasy syntaktycznej.

Historia i odmiany

Zasada abstrakcji jest wspomniana w kilku książkach. Niektóre z nich, wraz z formułą, jeśli jest zwięzła, są wymienione poniżej.

• Alfred John Cole, Ronald Morrison (1982) Wprowadzenie do programowania z S-algolem : „[Abstrakcja] zastosowana do projektowania języka polega na zdefiniowaniu wszystkich semantycznie znaczących kategorii składniowych w języku i umożliwieniu abstrakcji nad nimi”.
• Bruce J. MacLennan (1983) Zasady języków programowania: projektowanie, ocena i implementacja : „Unikaj wymagania, aby coś było powiedziane więcej niż raz; uwzględnij powtarzający się wzorzec”.
• Jon Pearce (1998) Programowanie i metaprogramowanie w schemacie : „Struktura i funkcja powinny być niezależne”.

Zasada odgrywa kluczową rolę we wzorcach projektowych w programowaniu obiektowym , chociaż większość prac na ten temat nie podaje nazwy tej zasadzie. W książce Design Patterns wydanej przez Gang of Four stwierdza się: „Nacisk kładziony jest tutaj na ujęcie koncepcji, która jest zmienna , temat wielu wzorców projektowych”. To stwierdzenie zostało przeformułowane przez innych autorów jako „Znajdź, co się zmienia i zamknij to”.

W tym stuleciu zasada została wymyślona na nowo w programowaniu ekstremalnym pod hasłem „Raz i tylko raz”. Definicja tej zasady była raczej zwięzła przy pierwszym pojawieniu się: „brak duplikatu kodu”. Zostało to później opracowane jako mające zastosowanie do innych zagadnień związanych z tworzeniem oprogramowania: „Zautomatyzuj każdy proces, który warto zautomatyzować. Jeśli wielokrotnie wykonujesz zadanie, napisz je”.

Implikacje

Zasada abstrakcji jest często podawana w kontekście jakiegoś mechanizmu mającego na celu ułatwienie abstrakcji. Podstawowym mechanizmem abstrakcji kontroli jest funkcja lub podprogram . Abstrakcje danych obejmują różne formy polimorfizmu typów . Bardziej rozbudowane mechanizmy, które mogą łączyć dane i abstrakcje kontrolne, obejmują: abstrakcyjne typy danych , w tym klasy , politypizm itp. Poszukiwanie bogatszych abstrakcji, które pozwalają na mniejsze powielanie w złożonych scenariuszach, jest jedną z sił napędowych badań i projektowania języków programowania.

Niedoświadczeni programiści mogą pokusić się o wprowadzenie do swojego programu zbyt dużej ilości abstrakcji — abstrakcji, która nie zostanie użyta więcej niż raz. Uzupełniającą zasadą, która podkreśla tę kwestię, jest „ Nie będziesz tego potrzebować ”, a bardziej ogólnie zasada KISS .

Ponieważ kod zwykle podlega rewizjom, przestrzeganie zasady abstrakcji może wiązać się z refaktoryzacją kodu. Wysiłek związany z przepisaniem fragmentu kodu ogólnie musi zostać zamortyzowany w stosunku do szacunkowych przyszłych korzyści płynących z abstrakcji. Praktyczna zasada, która to reguluje, została opracowana przez Martina Fowlera i spopularyzowana jako reguła trzech . Stwierdza, że ​​jeśli fragment kodu jest kopiowany więcej niż dwa razy, tj. skończyłby się na trzech lub więcej kopiach, to należy go wyabstrahować.

Uogólnienia

„ Nie powtarzaj się ” lub „zasada DRY” to uogólnienie opracowane w kontekście architektur wielowarstwowych , w których powiązany kod jest z konieczności powielany do pewnego stopnia na różnych poziomach, zwykle w różnych językach. W praktyce zaleca się poleganie na zautomatyzowanych narzędziach, takich jak generatory kodu i transformacje danych , aby uniknąć powtórzeń.

Sprzętowe interfejsy programowania

Oprócz optymalizacji kodu, hierarchiczne/rekurencyjne znaczenie poziomu abstrakcji w programowaniu odnosi się również do interfejsów między sprzętowymi warstwami komunikacyjnymi, zwanymi także „poziomami abstrakcji” i „warstwami abstrakcji”. W tym przypadku poziom abstrakcji często jest równoznaczny z interfejsem. Na przykład podczas sprawdzania kodu powłoki i interfejsu między językami wyższego i niższego poziomu poziom abstrakcji zmienia się z poleceń systemu operacyjnego (na przykład w C) na wywołania i polecenia na poziomie rejestru i obwodu (na przykład w asemblerze i binarnym). W przypadku tego przykładu granicą lub interfejsem między poziomami abstrakcji jest stos.