Pod koniec lat 80. w programowaniu nie działo się nic nowego. Było wiele języków, sporo kontrowersji i był Turbo Pascal 5.5, aw pakiecie jego dostarczania znajdowały się dziwne pliki i trochę nietypowe konstrukcje w składni.
Być może programowanie obiektowe zawdzięcza swój wygląd nieznanemu artyście, a być może kilku, ale idea łączenia kodu i danych w tamtych czasach nie miała szczególnie dużej wartości. Było luźno i pośrednio związane z pojęciem "enkapsulacji".
Już w pierwszych wersjach języków programowania, jeszcze przed pojawieniem się pierwszych baz danych, stało się absolutnie jasne, że nie jest to liczba lub ciąg znaków, ale coś znaczącego. Niech to będzie zmienny "licznik" w pętli lub trzy małe litery "nazwisko", "imię", "drugie imię", ale zawsze ma to sens od razu.
"Licznik" jest zawsze po cyklu i działa w nim. "Nazwisko", "imię", "drugie imię" zostaną ogłoszone obok siebie, a ich udział w wielu częściach kodu będzie wspólny. Gdzieś będą używane niezależnie, na ogół będą miały jedno znaczenie.
Funkcje i procedury pierwotnie pojawiły się jako częste kawałki kodu. Ich użycie było pierwotnie zamierzone w innym miejscu programu. Ich pojawienie się w programie spowodowało powtórzenie bloków tych samych akcji. Zrobienie powtórki w postaci funkcji lub procedury uproszczonych lokalizacji powtórzeń, zmniejszenie ilości kodu i uproszczone debugowanie.
Nie było to programowanie obiektowe, ale od samego początku jego ewolucji klasyczny styl kodowania był zaangażowany w kompilację danych, tworzenie struktur i funkcjonalnych sekcji kodu.
Enkapsulacja w programowaniu rozpoczęła się na długo przed pojawieniem się OOP. To było w głębi klasycznego stylu, oznaczało funkcjonalne programowanie, strukturalne i wszelkie inne, które starały się znaleźć drogę do przyszłości.
Każdy kompilator i tłumacz języka pilnie przyjmował wszystko, co nowe w swojej składni, oferował programistom opcje implementacji semantyki.
Informacje nigdy nie były statyczne, tylko programowanie nadal jest zadowolone z jego sformalizowanej wersji. Ale nawet będąc ściśle sformalizowanym, informacje zapewniają działanie kodu, który jest zawsze z nim związany. Informacje nigdy nie mogą być statyczne.
Najbardziej banalny przykład enkapsulacji, który został zachowany przez długi czas i ma znaczenie dla dzisiejszego dnia. Trzy zmienne "nazwisko", "imię", "drugie imię", gdziekolwiek się znajdują, zawsze wymagają funkcji dodawania, modyfikacji, usuwania. Co więcej, te zmienne zapewniają masę konkretnych osób, to jest wiele instancji:
Istnieje duża różnorodność takich konstrukcji na dowolnym poziomie (adresy, stanowiska, personel, plan produkcji). A złożoność implementacji innego projektu będzie niewiarygodnie długa.
Enkapsulacja to dane i kod.
Słowo "kapsuła" jest tym, co oznacza. Fakt, że wiele języków i deweloperów o tym pomyślał (publiczny, chroniony, prywatny) jest osobnym tematem i ma względny lub zastosowany związek ze znaczeniem enkapsulacji.
Ogólnie rzecz biorąc, instancja jest tylko opcją (nadrukiem, chwilą) danych, a te trzy metody żyją wiecznie. Kod jako filtr informacyjny "zapewnia" życie instancji, ponieważ jest to jeden dla wszystkich, a przy okazji, na razie :
Ale inna instancja może "wyrzucić" fokus.
Jeśli przykład zostanie przypisany do listy pracowników firmy, dyrektor i księgowy będą mieli specjalne znaczenie w zestawie kopii. Reszta może pozostać w zwykłej "formie". Dyrektor i księgowy mogą mieć własne kody, to znaczy ich własne funkcje.
Oznacza to, że życie instancji nie zawsze determinuje funkcjonalność trzech magicznych słów:
Jeśli przykład dotyczy pierwszego załogowego lotu w kosmos, tuzin kandydatów na pierwszych kosmonautów będzie miał wiele specjalnych funkcji, setka osób (okazy) obejrzy je w specjalny sposób, będzie znacznie więcej opcji dla specjalistów, którzy będą mieli bardzo wiele specjalnych. funkcje.
"Musimy pilnie coś zmienić" - pomyślała pewna liczba programistów i jako dobry przykład zaproponowali pracę z obiektami w Turbo Pascal 6.0 Professional. To nie jest idealna oferta, ale bardzo wysoka jakość jest prosta i skuteczna.
Zakładając, że "enkapsulacja, polimorfizm, dziedziczenie" jest podstawą obiektu, otrzymujemy dobry początek. Polimorfizm daje niezbędną dynamikę, ponieważ instancje mogą mieć różną funkcjonalność. Musi być jakoś "usankcjonowane" w obiekcie. Dziedziczenie pozwala odzwierciedlić jednorodność w obiekcie, aby zbudować genealogiczne drzewo sformalizowanych informacji.
Brzmi trudno. Zakładając, że enkapsulacja danych jest prostym połączeniem danych i kodu, wszystko staje się bardzo proste i pojawia się świetna koncepcja.
Obiekt to dane i kod. Instancja obiektu to tylko dane, do których ma dostęp jego kod. Może być wiele instancji, ale kod dla nich jest zawsze taki sam i nie jest dołączony do wszystkich, ale jest dostępny dla wszystkich.
Kiedy instancja obiektu wymaga szczególnej uwagi, pojawia się po prostu inny obiekt, który ma ulepszoną funkcjonalność, czyli dziedziczy wszystko, co było w oryginalnym obiekcie, ale dodaje coś własnego.
Świat jest uzupełniany instancjami drugiego obiektu, który również ma nowe potrzeby. Nowa funkcjonalność i nowy obiekt.
Ale nie każdy nowy obiekt może mieć potomków. Dla niektórych nie są już potrzebne. W wyniku takiej konstrukcji uzyskuje się rozgałęziony obraz obiektów, ale w rzeczywistości daje życie masie osobników powiązanych ze sobą rodowodem i powiązaniami funkcjonalnymi.
Idealnym wariantem realizacji zadań w stylu OOP jest to, że enkapsulacja, polimorfizm, dziedziczenie są tak przemyślane, że kod jest całkowicie nieobecny w programie. Obiekty same wykonują swoje funkcje, używają tylko swojego kodu, budują ze sobą relacje.
W rzeczywistości wszystko wygląda zupełnie inaczej. Hermetyzacja jest dobra i nie można tu dyskutować. Ale poprawne zobrazowanie obiektów, przemyślenie funkcjonalności każdej z nich, przewidzenie, jak zachowają się pewne okazy i czego można oczekiwać od danych, nie jest łatwe. Trzeba było uprościć sytuację, a OWP podążała ścieżką automatyzacji pracy dewelopera, zamiast rozwiązywać rzeczywiste problemy.
Z punktu widzenia szybkości zdobywania doświadczenia jest to w końcu skuteczny pomysł, dlaczego OOP powinien być zastosowany do automatyzacji pracy księgowej, kiedy można ją dołączyć do menu na stronie HTML?
Wszystko jest bardzo proste: istnieje element menu, są jego opcje. Możesz zaprosić użytkownika do wyboru opcji menu (pionowe, poziome, rozwijane), możesz przypisać przyciski do formularza (okrągłe, kwadratowe, zaokrąglone itp.).
Niewiele osób jest zainteresowanych pracą i życiem dewelopera. Każdy potrzebuje księgowości, produkcji, szkoleń, ponieważ musisz wykonywać prawdziwe zadania. Musisz więc zwiększyć liczbę kolektywów, ale wtedy system obiektów zostanie zaimplementowany przez różnych specjalistów i mogą zaszkodzić sobie nawzajem.
Pod wieloma względami stawia to OWP na szynach produkcyjnych. Nie było już żadnych wątpliwości: hermetyzacja, dziedziczenie to dobra droga, ale jak chronić przedmioty przed zewnętrzną ingerencją, zarówno z zewnątrz, jak i wzdłuż linii rodowodowej? Niekoniecznie będzie to haker. Przypadkowo wyrządzić szkody, zmieniając dane przodka, inny programista może.
Nowoczesne programowanie to dużo programistów w wielu odległych biurach. Podobnie jak pszczoły, nowocześni programiści budują jedną wspólną strukturę obiektów. Każdy obiekt powinien być zbudowany zgodnie z ogólnymi zasadami, a dane i metody, za które odpowiedzialny jest jeden programista, nie powinny być dostępne dla innych. Kiedy ktoś czegoś potrzebuje, to inny temat. Zgodnie z podstawową zasadą każdy robi swoją własną działalność we własnej witrynie.
PHPWord to potężny produkt, dobrze wykonany i obiecujący. Doskonały system przedmiotów, przemyślany i działający.
Poniżej znajduje się początek opisu wewnętrznego przedmiotu tego produktu. Jedna prosta abstrakcja komórki tabeli z ogólnie pustej abstrakcji - jakiś rodzaj pojemnika. I to nie jest wszystko opis.
Nie trzeba zanurzać się w dziczy, aby to zrozumieć. Wykorzystanie wielu komentarzy tutaj nie daje jasności, a słowa chronione, prywatne i publiczne, mówią, po pierwsze, że zewnętrzny twórca, korzystający z tej biblioteki, zmienił się prywatnie na publiczny we właściwym miejscu (patrz komentarz: "sc 06/19/2016 był prywatny
Jest to błąd w kodzie, który po zastosowaniu został zmuszony do korekty, a zatem musiał coś zmienić.
Można założyć, że na etapie rozwoju konieczne było ograniczenie dostępu do tych lub innych obiektów, ale tutaj ważna jest inna sprawa. Istnieje życie instancji, jest życie obiektów, ale jest już nowe życie - co się dzieje z systemem obiektów w jego zastosowaniu.
Życie w rozwoju i życiu w aplikacji. Charakterystyczną cechą współczesnego programowania jest sztywne zaprzeczenie ciągłości. Jeśli wcześniej programista zagwarantował, że każda nowa wersja uzupełni i ulepszy poprzednią, to dzisiaj każda nowa wersja obiektu, języka, środowiska programistycznego jest zasadniczo lub przynajmniej fundamentalnie odmienna od poprzedniej.
Nawet warunki hostingu na hostingu mogą się zmienić, więc musisz ponownie zmienić kod. I często jest to bardzo trudne.
Nikt nie jest odporny na błędy. I każdy nowy biznes wymaga wiedzy. PHPWord to dobra biblioteka i trzeba się do niej przyzwyczaić. Wielu profesjonalistów spędzało dużo czasu. Deweloper, który zebrał się, aby go użyć, powinien poświęcić wystarczająco dużo czasu na przestudiowanie struktury pliku Worda. To nie jest tajemnica.
System obiektowy PHPWord stanie się przejrzysty i dostępny. Podaje się go takim, jaki jest, ale jeśli istnieje chęć pójścia dalej, ponieważ obecna funkcjonalność jest niewystarczająca. Dobry pomysł. To jest inny system obiektów i lepiej, jeśli pójdzie dalej.
Nie jest tak źle, że trudno zaprzeczyć ciągłości: pobudza rozwój wiedzy. Obiekty zbudowane przez jeden zespół programistów to ich pomysły na rozwiązanie problemu, przedstawienie jego funkcjonalności.
Zrozumienie tego rozwiązania przez inną firmę deweloperską jest transformacją doświadczeń. Jeśli wyobrażamy sobie, że jest to tylko prototyp niezbędnego systemu obiektów, to dlaczego nie po prostu go odziedziczyć? Dobra dziedziczność - cecha naturalnej inteligencji, polegać na czymś, co jest adekwatne ze strony programowania - jest to z obszaru przyszłości, aczkolwiek najbliższego.
Enkapsulacja nie jest kombinacją danych i kodu. Jest to kombinacja tego, co jest dostępne i tego, co jest pożądane. Jeśli nie myślisz o danych i algorytmach, ale postrzegasz rzeczywistość i wykonujesz odpowiednią enkapsulację, dziedzicząc to działanie od dewelopera do programisty, to jest prawdopodobne: możliwe jest pojawienie się systemów obiektów poruszających się i rozwijających.