O ile jest oczywiste, że przejrzystość książki jest ważna dla czytelników to wydawać by się mogło, że kod programu nie musi być taki, bo komputer zawsze go zrozumie. To błąd!
Przejrzystość i czytelność artykułów, książek i innych publikacji zwłaszcza skierowanych do szerszego grona odbiorców nie podlega dzisiaj dyskusji. Nie inaczej należy traktować programy komputerowe, które też są tekstami tworzonymi by sterować systemami komputerowymi. O ile jednak systemom komputerowym jest obojętne czy program komputerowy jest czytelny czy nie to jest to ważne dla ludzi, którzy go tworzą, a ten proces jak pokazuje doświadczenie właściwie nigdy nie ma końca. Bowiem nawet jeśli udałoby się od razu wykonać program bezbłędny to praktyczne doświadczenia i uwagi użytkowników właściwie zawsze wpływają na kolejne zmiany w programie, których nie można dokonać jeśli kod programu jest niezrozumiały. Nawet gdyby pracę wykonywał jeden programista i od początku do końca ten sam to i tak musi odczytywać kod bo nie jest w stanie zapamiętać jak go napisał. A tym bardziej, że współczesne programy realizują wieloosobowe zespoły o często zmieniającym się z upływem czasu składzie.
Na początku był chaos. Pierwsze programy z lat pięćdziesiątych były bardzo zawikłane, bo starano się kodować jak najoszczędniej. Jedną z najgorszych praktyk z tamtych czasów było stosowanie instrukcji przeskoku(zwanej goto), która stosując analogię do czytania książki polegała na przechodzeniu do różnych wskazywanych w tekście numerów stron w celu kontynuowania czytania. Gorzej, że niektóre przejścia były warunkowe i zależały od tego czy dane rozwiązywanego problemu spełniały określony warunek np. arytmetyczny. Mnożącym się błędom zapobiegło programowanie strukturalne(eliminujące nieuporządkowane goto) i proceduralne(porządkujące kod w modułach) zainicjowane w latach sześćdziesiątych. Języki obiektowe zaczęto rozwijać dopiero od lat osiemdziesiątych(chociaż pierwsze pomysły implementowała już Simula z 1969 roku). Obiektowość najprościej rzecz ujmując polega na przypisywaniu do danych metod, które są jedynymi operacjami jakie na nich można wykonywać. W ten sposób chroni się dane przed przypadkowymi zmianami jak np. stan konta bankowego, na które można jedynie wpłacać i wypłacać, ale tylko do wysokości salda. Paradygmat Model-View-Controler (MVC) upowszechnia się dopiero w ostatnich latach, chociaż jego źródeł można szukać w roku 1979.
Najogólniej rzecz biorąc MVC polega na podziale programu na trzy warstwy kodu często umieszczane w odrębnych katalogach:
- Model – jest pewną reprezentacją problemu bądź logiki aplikacji.
- Widok – opisuje, jak wyświetlić pewną część modelu w ramach interfejsu użytkownika.
- Kontroler/Sterownik – przyjmuje dane wejściowe od użytkownika i reaguje na jego poczynania, zarządzając aktualizacje modelu oraz odświeżenie widoków.
Wyraża to najprościej następujący schemat:
Stanie się to jeszcze prostsze, gdy przyjmiemy, że programem jest gra komputerowa.Wtedy można uszczegółowić zadania poszczególnych modułów przypisując im konkretne funkcje w obsłudze gry:
Oczywiście bardzo podobnie jest we wszelkich innych programach. Paradygmat MVC okazał się szczególnie użyteczny w tworzeniu przeglądarkowych aplikacji internetowych. Można go realizować nawet z użyciem popularnego języka PHP, aczkolwiek powstało już wiele innych języków programowania lepiej zorientowanych na paradygmat MVC.