Programowanie obiektowe to paradygmat, czyli pogląd na to, jak należy programować. Wkrótce sam się przekonasz, że OOP przynosi całkiem zasadnicze uproszczenie wszystkich typowych problemów i trudności, które są wciąż i wciąż rozwiązywane w prawdziwym programowaniu.
Podstawową ideą programowania obiektowego jest podzielenie dużej aplikacji (złożonego zadania) na wiele małych części, które możemy rozwiązać elegancko i niezależnie od siebie.
Na przykład, jeśli programujemy system rezerwacji biletów lotniczych, jest to bardzo złożony projekt, który rozwiązuje tysiące spraw. Jeśli uda nam się rozłożyć całą złożoną logikę na wiele warstw i części, będziemy mogli łatwo zrozumieć cały złożony system i niezależnie programować poszczególne podzadania.
Poza naukowym punktem widzenia istnieje wiele praktycznych powodów, dla których warto stosować OOP:
Osobiście nie wyobrażam sobie, aby zespoły, w których pracuje więcej niż jedna osoba, mogły programować w inny sposób.
Uwaga:
Używanie obiektów obciąża komputer nieco większą ilością pamięci i procesora, dlatego też może to nieco obniżyć wydajność aplikacji. W rzeczywistym środowisku nie ma to jednak znaczenia, ponieważ przeprogramowanie aplikacji na obiekty powoduje pewne straty w wydajności (zwykle rzędu kilku procent), ale oszczędza czas programistów (zwykle dziesiątki do setek procent). Czas ludzki jest zawsze dużo droższy (i bardzo ograniczony) niż czas komputerowy.
Nie zapominajmy też, że OOP bardzo upraszcza całą aplikację i pozwala na ukończenie dużych aplikacji w rozsądnym czasie. Wiele złożonych aplikacji byłoby prawie niemożliwych do zaprogramowania bez obiektów.
Podstawowym celem OOP w projektowaniu oprogramowania jest jak najdokładniejsze symulowanie właściwości, zachowań i zasad świata rzeczywistego. Obiekty w OOP reprezentują rzeczywiste byty. Ten sposób myślenia pozwala nam budować ogromne, złożone systemy, które można dobrze zrozumieć, rozwiązywać problemy świata rzeczywistego w sposób wewnętrzny, tak jak byłyby one rozwiązywane bez komputera, a zasady działania można wyjaśnić prawdziwym ludziom.
Na przykład, jeśli wdrażamy aplikację do zarządzania treścią, sensowne jest umieszczenie całej wewnętrznej logiki w wielu rzeczywistych encjach (artykuł, autor, kategoria) i budowanie sesji nie według sztucznie wygenerowanych identyfikatorów rekordów (jak to się tradycyjnie robi w bazach danych), ale według rzeczywistych relacji.
Przykład konkretnej implementacji:
class Article{private Author $author;/** @var Kategoria[] */private array $categories;private string $title;}class Author{private string $name;}class Category{private string $name;}
Jak widać, klasa Article
nie tylko zawiera parametry techniczne, takie jak identyfikator rekordu z autorem, ale jest rzeczywistym powiązaniem z encją Author, która również ma swoje własne właściwości.
Wyjaśnienia dotyczące konkretnej implementacji i składni można znaleźć w tutorialu wprowadzającym.
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu:
Články píše Jan Barášek © 2009-2024 | Kontakt | Mapa webu
Status | Aktualizováno: ... | pl