programistyczna semantyka ontologii
TRANSCRIPT
Próba znalezienia programistycznej semantyki ontologii
Streszczenie
W pracy tej postaram si¦ pokaza¢ istnienie bardzo silnej analogii pomi¦dzy j¦zy-
kami programowania (konkretnie paradygmatem Obiektowo�Orientowanym) a j¦-
zykiem w jakim opisujemy ±wiat � ontologi¡.
Postaram si¦ wskaza¢ ¹ródªo tej analogii. Jak równie» wyci¡gn¡¢ z tej analo-
gii wnioski, rozwi¡zuj¡c kilka bie»¡cych problemów ontologicznych. By to zrobi¢
wska»¦ reguªy korespondencji pomi¦dzy terminami C++ a ontologii (czyli de facto
zde�niuj¦ terminy ontologii poprzez terminy C++).
Uwaga
Niestety ta praca, nie jest rozpowszechniana na otwartej licencji. Prosz¦ nie: wyko-
nywa¢ lokalnych kopii, nie publikowa¢. U»ycie stricte niekomercyjne.
Dzi¦kuj¦
Dzi¦kuje doktorowi Grygia«cowi za przyj¦cie pracy i cenne uwagi.
i
SPIS TRE�CI ii
Spis tre±ci
1 Wst¦p 1
1.1 Uwagi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.1 J¦zyki programowania . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 Skªadnia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3 Adekwatno±¢ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.4 Przypisy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Ugruntowanie 3
3 Technikalia 3
3.1 Sprawy elektroniczne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.1.1 O pami¦ci komputera . . . . . . . . . . . . . . . . . . . . . . . . . 43.1.2 Ukªad elektroniczny . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 O efektywno±ci 5
5 Zmienne 5
6 Kontekst 6
7 Klasy 6
7.1 Skªadnia klasy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8 Analogia ontologiczna 9
8.1 Wnioski z analogii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9 O cechach idei 12
9.1 Teza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129.2 Analogia informatyczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129.3 O Plotynie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149.4 Rozwi¡zanie problemu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149.5 Wyja±nienie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10 Pluralizm a ewentyzm 14
10.1 Analogia informatyczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1410.2 Odniesienie do ontologii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11 O rodzajach cech 15
11.1 Analogia informatyczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511.2 O Spinozie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611.3 Odparcie argumentu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611.4 Pewien problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12 Dziedziczenie, czyli nowa hierarchia idei 17
12.1 Detale techniczne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712.2 Analogia ontologiczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13 Zako«czenie 19
SPIS TRE�CI iii
14 Apendyks I
14.1 Cytat z �Thinking in C++� . . . . . . . . . . . . . . . . . . . . . . . . . . I14.2 Wycinek ze strony z Wikipedii o programowaniu obiektowo orientowanym I
1 WST�P 1
1 Wst¦p
Gdy poznawaªem podstawowe poj¦cia ontologii, uderzaªo mnie ich podobie«stwo zna-
czeniowe do poj¦¢ u»ywanych w opisie paradygmatu programowania obiektowego. Nie
jest jednak moim celem opisanie tego podobie«stwa, bowiem byªoby to bezproduktywne
zaj¦cie1. Nie jest moim celem te» stworzenie reguª korespondencji, bowiem to te» byªoby
samo w sobie bezproduktywne. W pracy tej postawiªem potraktowaªem paradygmat
programowania obiektowo orientowanego jako analogi¦ dla otologii. I postaraªem si¦ wy-
ci¡gn¡¢ z tej analogii jak najwi¦cej sensownych wniosków. �wiat jest niesko«czenie skom-
plikowany, paradygmat programowania za± jest bardzo prosty. �wiat jest niesko«czenie
wielki, programowanie za± stanowi maªy jego wycinek.
Pewne wªasno±ci ±wiata s¡ nie widoczne, bowiem czªowiek nie mo»e posiada¢ do niego
odpowiedniej perspektywy (perspektywa pochodzi od oddalenia, a trudno jest oddali¢ od
±wiata, przykªadowo bez programowania nie wpadªbym na przykªad z sekcji 9, umoty-
wowanie tego zdania znajduje si¦ w sekcji 9.5), natomiast s¡ widoczne w programowaniu
bowiem tam mo»na mie¢ j¡ mie¢. Po zauwa»eniu takiej wªasno±ci w programowaniu
mo»na dan¡ cech¦ zauwa»y¢ w ±wiecie, w ontologii.
1Istnienie analogii niczego jeszcze nie dowodzi. Przykªadowo jest znanym faktem »e ilo±¢ pªatkówprzytªaczaj¡cej wi¦kszo±ci gatunków kwiatów (jak i np. ilo±¢ ziaren w kwiecie sªonecznika) jest liczb¡Fibonacciego. Liczby Fibonacciego s¡ de�niowane rekurencyjnie wedle zasady:
Ψ0 = 0
Ψ1 = 1
Ψn = Ψn−1 + Ψn−2
Pierwszych 15 liczb z tego ci¡gu to: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987.Sam ten fakt, samo poª¡czenie pomi¦dzy matematyk¡ a biologi¡ niczego nie dowodzi i jest pró»ne.
Ciekawym mo»e by¢ tylko po wskazaniu korzenia analogii. Wa»nym po wskazaniu jej zastosowa«.Fakt ten ma wyja±nienie. W telegra�cznym skrócie (du»o lepiej jest to wyja±nione w [9, rozdz. 9, str.
162�171]) wynika to z dynamiki rozwoju ªodygi. Kolejne zawi¡zki s¡ umieszczane w sto»ku rozwoju naszczycie ªodygi co ustalony czas (podczas którego ro±lina ro±nie, czyli poszerza si¦), pod staªym k¡temdo ostatniego zal¡»ka. Gdyby zal¡»ki powstawaªy ci¡gle, tworzyªyby spiral¦. By t¦ metod¡ upakowa¢na pªaszczy¹nie jak najwi¦cej punktów k¡t ten musi by¢ niewymierny, a co wa»niejsze � bardzo nie-wymierny (czyli ¹le aproksymowalny kolejnymi liczbami wymiernymi). Jedn¡ najgorzej aproksymowan¡liczb¡ niewymiern¡ jest tzw. zªota liczba de�niowana jako:
Φ = limn→∞
Ψn−1
Ψn
Czyli stosunek kolejnych liczb Fibonacciego. Ilo±¢ tak tworzonych w ten sposób zaznaczanych punktówna zewn¦trznym zwoju spirali jest liczb¡ Fibonacciego.Sama analogia nic nie znaczyªa. Znacznie miaªo dopiero jej wyja±nienie.
1 WST�P 2
1.1 Uwagi
1.1.1 J¦zyki programowania
B¦d¦ posªugiwaª gªównie C++ (jak te» i jego skªadni¡) i b¦d¦ odnosiª si¦ do Javy,
w punktach w których j¦zyki te si¦ ró»ni¡2. W dwóch miejscach odnios¦ si¦ do innych,
nienazwanych, j¦zyków programowania.
C++ wybraªem na podstawowy j¦zyk pracy, gdy» jest on jednym z najbardziej roz-
powszechnionych j¦zyków programowania i ma on najszersze spektrum zastosowa«. Java,
jako drugi j¦zyk którym wspieram si¦ w pracy, jest najpopularniejszym j¦zykiem, ale ma
w¦»sze spektrum zastosowa«.
Postanowiªem u»y¢ wielu j¦zyków, gdy» istnienie czy nieistnienie ró»nic pomi¦dzy
tymi j¦zykami wskazuje mi na pewno±¢/niepewno±¢ analogii w danym punkcie. Tam
gdzie j¦zyki b¦d¡ zgodne, b¦d¦ miaª pewno±¢ »e analogia jest dobra. Tam gdzie b¦d¡ si¦
ró»ni¢, b¦dzie sªaba (lub jej nie b¦dzie).
1.1.2 Skªadnia
Podczas pisania pierwszej wersji pracy, zauwa»yªem »e samo wprowadzenie do skªadni
C++ zajmuje wi¦cej miejsca ni» wªa±ciwa tre±¢ ontologiczna. Postanowiªem wi¦c zredu-
kowa¢ do absolutnego minimum zarówno u»ywanie samej skªadni, jak te» i wprowadzanie
do niej. Nie pojawi si¦ w pracy jeden dziaªaj¡cy program, ani jedna linia kodu nie b¦d¡ca
deklaracj¡.
Musz¦ jednak poczyni¢ pewn¡ umow¦: wszystkie nazwy b¦d¡ce identy�katorami,
czyli nazwami wªasnymi konkretnych tworów programowania, b¦d¡ drukowane czcionk¡
maszynow¡.
1.1.3 Adekwatno±¢
Doªo»yªem wszelkich stara«, »eby w pracy uj¡¢ skomplikowane poj¦cia prostym j¦zy-
kiem, nie u»ywaj¡c tzw. kªamstw dla dzieci, czyli nie upraszczaj¡c nadmiernie. Ogólnie
mi si¦ to udaªo. Natomiast zdecydowaªem si¦ nie wprowadza¢ poj¦cia wska¹nika, które,
co wiem z do±wiadczenia, sprawia osobom nie obeznanym z programowaniem wielkie
problemy, oraz które wymaga wprowadzenia kilku innych poj¦¢. Wad¦ t¡ wida¢ gªównie
cz¦±ci traktuj¡cej o to»samo±ci.
1.1.4 Przypisy
Przy poprawianiu pracy wpadªem na trop wielu ciekawych rozwini¦¢ zagadnie« w
niej uj¦tych, odkryªem »e niektóre cz¦±ci pracy wymagaj¡ doprecyzowania, czy podania
dodatkowego przykªadu. W przypadkach gdy dopiski te nie s¡ ±ci±le powi¡zane z tokiem
2Ogólnie j¦zyki te ró»ni¡ si¦ bardzo, ale w tak podstawowych poj¦ciach, które b¦d¡ w pracy przed-stawione s¡ bardzo podobne
2 UGRUNTOWANIE 3
wywodu, umie±ciªem je w przypisach. Ponadto b¦d¦ ich u»ywaª gdy, b¦dzie mi zale»aªo
na utrzymaniu podaniu informacji zachowuj¡cych adekwatno±¢ merytoryczn¡ pracy (w
kontek±cie programowania), a gdy podanie ich w tek±cie zaciemniaªo by jego tre±¢.
2 Ugruntowanie
Postaram si¦ teraz pokaza¢, dlaczego paradygmat programowania stanowi analogi¦
do ontologii (czyli paradygmatu3 postrzegania ±wiata).
Po pierwsze, programy wspóªpracuj¡ ze ±wiatem� z maszynami i z lud¹mi. Programy
steruj¡ce jak¡± maszyn¡ maj¡ struktur¦ podobn¡ do niej samej � je±li maszyna ta ma
dziesi¦¢ ró»nych bloków funkcyjnych, to dobrze napisany program te» b¦dzie miaª dziesi¦¢
bloków odpowiadaj¡cych blokom maszyny. Programy modeluj¡ ±wiat. Istniej¡ (powstaªe
dla rozrywki, ale funkcjonuj¡ce.) modele ±wiata i s¡ to modele dobre. Mam tu na my±li
komputerowe gry MMORPG4. A przecie» model jest dobrym modelem gdy ma struktur¦
tego co modeluje.
Po drugie, paradygmat programowania ewoluowaª (cho¢ byªa to szybka ewolucja) w
stron¦ paradygmatu obiektowo orientowanego. Ewoluowaª w t¦ stron¦, nie dlatego, »e
programy napisane w ten sposób s¡ szybsze czy wydajniejsze (w istocie jest wprost prze-
ciwnie), ale dlatego, »e ich tworzenie i konserwacja5 s¡ szybsze. J¦zyki programowania
ewoluowaªo w stron¦ bycia przystosowanym do czªowieka a nie do komputera.
3 Technikalia
Niestety, nie mog¦ zakªada¢, »e czytelnik jest obeznany z terminologi¡ programi-
styczn¡, postaram si¦ wi¦c teraz j¡ przybli»y¢.
Kompilacja to proces automatycznego tªumaczenia kodu napisanego w jednym j¦zyku
programowania na drugi. Dane wej±ciowe najcz¦±ciej nazywa si¦ kodem ¹ródªo-
wym. Program wykonuj¡cy tªumaczenie to kompilator. [1, hasªo: kompilacja]
Sªowa tego jednak najcz¦±ciej u»ywa si¦ gdy kod ¹ródªowy jest j¦zykiem programo-
wania wy»szego poziomu ni» kod wynikowy - w szczególno±ci, gdy kod wynikowy
to kod maszynowy (kod czytelny bezpo±rednio dla procesora, czyli zawarto±¢ pliku
.exe).
3Paradygmat pochodzi od greckiego parádeigma `obraz', a dzi± znaczy: �przyj¦ty sposób widzeniarzeczywisto±ci w danej dziedzinie, doktrynie itp� [3], �zbiór zaªo»e«, poj¦¢, warto±ci, praktyk, konsty-tuuj¡cych sposób patrzenia na rzeczywisto±¢ dla konkretnej spoªeczno±ci, w szczególno±ci dotyczy to[spoªeczno±ci] poszczególnych dyscyplin intelektualnych.� [4, hasªo: paradigm, tªumaczenie wªasne]
4Massive Multiplayer Online Role Playing Game, czyli Wielkie Sieciowe Gry Odtwarzania Ról. Graczetych gier wcielaj¡ si¦ w ró»ne postacie i znajduj¡ rozrywk¦ w odgrywaniu ich.
5Z angielskiego `maintain'. Nie chodzi o konserwacj¦ w takim znaczeniu w jakim wyst¦puje w zda-niu �Konserwacja pieca�, bowiem programy si¦ nie psuj¡. Przez konserwacj¦ rozumiem np. dodawanienowej wymaganej przez klienta funkcjonalno±ci, dostosowywanie programu do zmian np. w standardachsieciowych, czy w sprz¦cie komputerowym.
3 TECHNIKALIA 4
Dekompilacja to proces odwrotny do kompilacji, tj. tªumaczenie j¦zyka niskiego po-
ziomu na j¦zyk wysokiego poziomu. Nigdy nie da si¦ podczas dekompilacji caªko-
wicie odtworzy¢ kodu wy»szego poziomu; prawie zawsze nast¦puje utrata cz¦±ci
struktury programu.
J¦zyk zupeªny w sensie Turinga Jest to j¦zyk programowania, w którym da si¦ roz-
wi¡za¢ ka»dy algorytmowalny problem, czyli da si¦ napisa¢ w nim ka»dy program.
Uwaga! Bardzo wa»nym jest to »e prawie zawsze j¦zyk programowania jest zu-
peªny w sensie Turinga, bowiem warunki dostateczne ku temu s¡ bardzo proste do
speªnienia.
Powiem wi¦cej, warunki te s¡ tak proste, »e czasem twory komputerowe które, nie
s¡ j¦zykami programowania, czy te» nie byªy pomy±lane jako takie, s¡ zupeªne w
sensie Turinga. Przykªadem mo»e by¢ LATEX � j¦zyk skªadania tekstu w którym
pisz¦ t¦ prac¦, jest on zupeªny w sensie Turinga niejako przypadkiem.
Argument ten wykazuje, »e rozwój programowania szedª w kierunku uªatwiania
ludziom pisania trudnych programów, a nie zwi¦kszania mo»liwo±ci programów w
ogóle, mo»liwo±ci pisania programów w ogóle osi¡gn¦ªy swoj¡ granic¦ dawno temu.
3.1 Sprawy elektroniczne
Niestety, b¦d¦ musiaª odwoªa¢ si¦ do pewnych technicznych detali, które posªu»¡ za
wa»ne przykªady w dalszej cz¦±ci pracy (sekcja 9).
3.1.1 O pami¦ci komputera
Pami¦¢ komputera skªada si¦ z kilkubajtowych komórek6 poªo»onych liniowo � zna-
czy to, »e »eby zna¢ poªo»enie konkretnej komórki musz¦ zna¢ jedn¡ liczb¦ (jej adres)7.
Tym, co jest tak naprawd¦ wa»ne jest to »e pami¦¢ komputera nie zawiera »adnej in-
formacji o tym, co przechowuje (»adnego kontekstu). Nie wiemy nawet gdzie zaczyna
si¦ w niej jedna dana, a ko«czy inna. Przykªadowo nie wiemy, czy dany blok informacji
to dwadzie±cia ró»nych liczb dziesi¦tnych, czy jaki± ci¡g znaków. Kontekst pojawia si¦
dopiero w programie, czyli w sposobie przetwarzania danych.
3.1.2 Ukªad elektroniczny
De�niuje ukªad elektroniczny jako urz¡dzenie, które na okre±lony rozkªad stanów na
wej±ciach reaguje okre±lonymi stanami na wyj±ciach. Jest to de�nicja o tyle adekwatna
»e jest niezale»na od konkretnej implementacji technicznej � nie ma znaczenia, czy
ukªad oparty jest na diodach, tranzystorach bipolarnych, tranzystorach polowych, czy
6Zale»nie od architektury procesora mog¡ warto±ci te mog¡ by¢ bardzo ró»ne.7Adres mo»e mie¢ kilka cz¦±ci o ró»nych znaczeniach, ale jest to jedna liczba. Przykªadowo: adres to
XYZ (np. 123) i X to adres bloku pami¦ci, a YZ komórki w bloku pami¦ci.
4 O EFEKTYWNO�CI 5
na ukªadzie mechanicznym8. De�nicja ta jest caªkowicie niezale»na od ±wiata. W tym
poj¦ciu ukªadu elektronicznego zupeªnie nie interesuje nas on dziaªa � wystarcza »e w
ogóle dziaªa.
4 O efektywno±ci
Cho¢ ka»dy program da si¦ napisa¢ w ka»dym j¦zyku programowania, to napisanie
programu w ró»nych j¦zykach programowania mo»e wymaga¢ ró»nych ilo±ci pracy. Mo»na
spyta¢ (i b¦dzie to pytanie zasadne), dlaczego nie u»ywa si¦ tylko jednego � najopty-
malniejszego j¦zyka. Odpowiedzie¢ mo»na na dwóch pªaszczyznach. Po pierwsze ró»ne
j¦zyki programowania nadaj¡ si¦ lepiej do ró»nych celów9. Po drugie im mniej pracy
wykonuje programista podczas pisania programu, tym wi¦cej czasu potrzebuje kompu-
ter na wykonanie go. Bowiem j¦zyk programowania przystosowany do czªowieka, nie jest
przystosowany do komputera i vice versa.
J¦zyki przystosowane do komputera zwane s¡ j¦zykami niskiego poziomu, nato-
miast te przystosowane do czªowieka zwane s¡ j¦zykami wysokiego poziomu10.
Jeszcze raz podkre±l¦. Wszystkie j¦zyki zupeªne w sensie Turinga maj¡ te same mo»-
liwo±ci, ludzie maj¡ ró»ne mo»liwo±ci u»ywania ich.
5 Zmienne
Ka»dy j¦zyk programowania ma przynajmniej cztery typy zmiennych11.
Uwaga! Zmienna ma tu troch¦ inne znaczenie ni» w logice czy matematyce. Zmienna
liczbowa jest tak naprawd¦ konkretn¡ liczb¡, której warto±¢ mo»e si¦ zmienia¢ w trakcie
8Da si¦ wykona¢ mechaniczn¡ maszyn¦, dla której istnieje j¦zyk programowania zupeªny w sensieTuringa. Plany takiej maszyny stworzyª Charles Babbage w dziewi¦tnastym wieku, niestety maszyna wcaªej okazaªo±ci nie powstaªa nigdy, lecz powstawaªy jej prostsze wersje.
9Przykªadowo istniej¡ j¦zyki skryptowe, w których prawie ka»de polecenie to polecenie systemu ope-racyjnego dziaªaj¡cego na danym komputerze (przykªadowo maj¡ polecenie copy). Bez takich j¦zykówzarz¡dzanie sieci¡ stu komputerów byªoby koszmarem.Istniej¡ j¦zyki w których gªówny nacisk poªo»ono na przeno±no±¢ programów pomi¦dzy komputerami.
Programy napisane w C++ (poza najprostszymi) napisane dla Windowsa, nie skompiluj¡ si¦ pod Linu-xem. A nawet je±li si¦ skompiluj¡, to mog¡ dawa¢ inne wyniki (poniewa» C++ wykorzystuje wszystkiemo»liwo±ci komputera, i np. na nowszym komputerze b¦dzie dokonywaª dokªadniejszych oblicze« nume-rycznych). W j¦zykach tych pisze si¦ gªównie programy dla Internetu.Istniej¡ j¦zyki w których nacisk poªo»ono na mo»liwo±¢ zmieniania programu w trakcie jego wykonania.
W C++ nie da si¦ tego zrobi¢ � mo»na oczywi±cie wpªywa¢ na to które fragmenty programu zostan¡wykonane, ale nie mo»na w trakcie dziaªania programu dopisa¢ jego kawaªka. W tych j¦zykach gªówniepisze si¦ programy dla �rm zajmuj¡cych si¦ telefoni¡ � sieci telefoniczne musz¡ si¦ rozwija¢ (dodawa¢funkcjonalno±¢) a ich programy musz¡ dziaªa¢ non�stop.Przykªady te s¡ troch¦ na boku rozwa»a«, ale posªu»¡ mi do odrzucenia paru wniosków, która inaczej
mogªyby pªyn¡¢ z moich rozwarza«.10Nota historyczna: J¦zyki programowania niskiego poziomu byªy wa»ne w czasach, w których kom-
putery byªy bardzo wolne i bardzo drogie. Wtedy opªacaªo zatrudni¢ wielu programistów, by napisaliprogram, który wykonuje si¦ bardzo szybko. Teraz nie ma ju» takiej konieczno±ci, i j¦zyki wysokiegopoziomu s¡ du»o popularniejsze.
11Równolegle stosuje si¦ termin identy�kator.
6 KONTEKST 6
wykonywania programu. Jest ona zmienn¡ w tym sensie, »e pisz¡c program nie wiemy,
jaka jest jej warto±¢ w danym miejscu kodu ¹ródªowego.
Typy zmiennych:
int liczba caªkowita z ustalonego zakresu. Np: `4'.
�oat liczba rzeczywista okre±lona z ustalon¡ dokªadno±ci¡. Np.: `3.14159265'.
char litera z ustalonego zbioru liter. Np.: `a'.
string ci¡g liter. Np.: �Ala ma kota�.
6 Kontekst
J¦zyk zupeªny w sensie Turinga musi posiada¢ przynajmniej jedn¡ zmienn¡. Ponadto
ka»da ze zmiennych wymienionych w poprzedniej sekcji redukuje si¦ do jednego typu da-
nych � do liczby binarnej u»ywanej w trzewiach komputera. Po co wi¦c s¡ a» cztery
(a w prawdziwych j¦zykach programowania kilkakrotnie wi¦cej) typy zmiennych, skoro
ka»da z nich jest liczb¡ binarn¡? Jest tak poniewa» liczby binarne s¡ rozumiane w innych
kontekstach. Tak wi¦c je±li programista napisze:
wy±wietl(nazwaZmiennej);
Program wykona ró»ne operacj¦ w zale»no±ci od typu zmiennej (przecie» inaczej wy±wie-
tla si¦ liczb¦, a inaczej znak � liczba 01001 jako liczba dziesi¦tna to 9, a jako znak
to znak tabulacji12). Oczywi±cie programista mógªby poradzi¢ sobie bez tego kontekstu.
U»ywaªby wtedy:
wy±wietlLiczb¦Caªkowit¦(5);
wy±wietlZnak('b');
Gdzie funkcja wy±wietlLiczb¦Caªkowit¦ wy±wietlaªaby poprawnie liczby caªkowite, a
wy±wietlZnak � znaki. Jednak obci¡»aªo by to pami¦¢ programisty oraz pozwalaªoby
na popeªniania bª¦dów:
wy±wietlLiczb¦Caªkowit¦(�Ala ma kota�);
Zmienna b¦d¡ca ci¡giem liter jest te» redukowalna do liczby binarnej, wi¦c komputer
mo»e j¡ potraktowa¢ jako dowolny inny typ zmiennej, w szczególno±ci jako liczb¦ caª-
kowit¡ i co± wy±wietli¢. Ale b¦dzie to bª¡d logiczny. Typy danych wprowadzono wªa±nie
po by takich bª¦dów unika¢.
7 Klasy
Zmienne mo»na organizowa¢ w dowolny sposób (jeden z przydatniejszych podano w
ostatniej sekcji). Jaki jednak jest najwygodniejszy z punktu widzenia programisty? Ten,
do którego programista ju» przywykª � sposób, w którym zorganizowanie s¡ przedmioty
w otaczaj¡cym programist¦ ±wiecie.
12w kodowaniu ASCII.
7 KLASY 7
Obiekty dopasowane do problemu wyra»aj¡ go lepiej [ni» suche dane -przyp
mój ]. Co znaczy: pisz¡c kod, opisujesz rozwi¡zanie w terminach przestrzeni
do której nale»y sam problem (�Poªó» przykrywk¦ na kosz na ±mieci�), a
nie w terminach komputera, który jest przestrzeni¡, w której nast¡pi roz-
wi¡zanie (�Ustaw ten bit na �adze stanu kosza który oznacza »e jest on
zamkni¦ty�). U»ywasz poj¦¢ z wy»szego poziomu i mo»esz wykona¢ wi¦cej
jedn¡ lini¡ kodu13.[tªumaczenie wªasne]
[7, rozdziaª 1]14
Sposobem organizowania danych, czyli zapewniania kontekstu, s¡ klasy.
Klasa to (. . . ) de�nicja dla obiektów, b¡d¹ te» zbiór wszystkich obiektów, maj¡cych
wspóln¡ struktur¦ i zachowanie. [1, hasªo: klasa (programowanie obiektowe)]
Klasa de�niuje abstrakcyjn¡ charakterystyk¦ jakiego± przedmiotu, czyli jego przymioty
b¡d¹ wªasno±ci, jak i mo»liwo±ci (jego zachowanie). Dla przykªadu: klasa Pies skªa-
daªaby si¦ wszystkich cech wspólnych wszystkim psom � rasy, koloru sier±ci, umie-
j¦tno±ci szczekania (. . . )
[2, hasªo: Object-oriented programming, tªumaczenie wªasne]
Obiekt to w programowaniu konkretna instancja klasy. Klasa pies de�niuje wszystkie
mo»liwe psy wyszczególniaj¡c ich charakterystyk¦; obiekt Lessie jest konkretnym
psem, z konkretnymi warto±ciami charakterystyk. Pies ma futro; Lessie ma br¡-
zowo-biaªe futro. (. . . ) Zbiór warto±ci charakterystyk konkretnego obiektu nazy-
wany jest jego stanem. [Tªumaczenie wªasne]
[2, hasªo: Object-oriented programming, tªumaczenie wªasne]
Metoda to jedna z umiej¦tno±ci obiektu. Lessie, b¦d¡c psem, posiada umiej¦tno±¢
szczekania, wi¦c szczeknij() jest jedn¡ z jej metod. (. . . ) Wszystkie psy potra�¡
szczeka¢, ale potrzeba konkretnego psa do zaszczekania.[Tªumaczenie wªasne]
[2, hasªo: Object-oriented programming]
Co dokªadnie znaczy stwierdzenie, »e klasa jest de�nicj¡? W jakim sensie jest tu
rozumiane sªowo de�nicja? Samo poj¦cie de�nicji ewoluowaªo w trakcie rozwoju technik
programowania.
Najpierw poprzez de�nicj¦ rozumiano podanie jakie dane zawieraj¡ obiekty danej
klasy, potem podanie danych oraz metod (wªa±ciwo±ci oraz mo»liwo±ci) jakie posiadaj¡
obiekty danej klasy.
13Oczywi±cie odniesienie do przestrzeni komputera (w przykªadzie `ustawianie bita') te» wyst¡pi wprogramie, ale wyst¡pi ono raz � w de�nicji polecenia �poªó» przykrywk¦ na kosz na ±mieci�, a dalej wprogramie b¦dzie pojawiaªo si¦ ukryte wªa±nie pod tym poleceniem.
14Jeden z lepszych podr¦czników programowania w C++.
7 KLASY 8
Teraz uznaje si¦, »e wystarczy poda¢ tylko metody. W naszej ontologii15 oznacza to
»e de�nicj¡ universale jest podanie jego cech bez podania materii pierwszej któr¡ b¦d¡
zawieraªy egzempli�kacje.
Same dane nie interesuj¡ programisty korzystaj¡cego z danej klasy. Interesuj¡ go mo»-
liwo±ci, nie jest dla niego istotne, jak konkretnie je zaimplementowano (w jaki sposób
zostaªy one napisane). Wszystkie dane (zmienne) ukrywa si¦ przed programist¦ korzy-
staj¡cym z danej klasy. Ma on dost¦p tylko do metod.
7.1 Skªadnia klasy
class dog{private:
float wiek;Kolor kolorSier±ci;float wysoko±¢;
public:void zaszczekaj() (...);void siad() (...);void podajWiek() (...);void wpu±¢DoDomu(Osoba kogo) (...);
}
Ka»da klasa ma dwie wa»ne sekcje: prywatn¡ i publiczn¡. W cz¦±ci prywatnej s¡ te
elementy klasy, do których nie ma dost¦pu z zewn¡trz klasy. W cz¦±ci publicznej s¡ te
cz¦±ci do których dost¦p jest. Dost¦p do elementów klasy ogranicza si¦ z dwóch powodów.
Pierwszym jest to, »e elementy prywatne mo»na dowolnie zmienia¢ w kolejnych wersjach
programu i ich zmiana nie wpªynie na reszt¦ programu (gdyby±my usun¦li psu zmienn¡
wiek, a gdzie± w programie byªaby ona odczytywana bezpo±rednio, to nale»aªo by i to
miejsce zmieni¢). Drugi powód jest bardziej skomplikowany i wrócimy do niego potem.
Wyja±nienie skªadni klasy:
Zmienne klasy podaje si¦ w formie:
tym_zmiennej nazwa_zmiennej;
Metody klasy podaje si¦ w formie:
typ_zwracany nazwa_funkcji(lista parametrów) tre±¢ funkcji
Wyja±nienie skªadni metod:
typ_zwracany Przykªadowo funkcja podajWiek zwraca nam wiek, czyli liczb¦, funkcja
podajKsztaªt zwraca ksztaªt. Typ zwracany wskazuje na to, jakich danych mo»emy si¦
spodziewa¢ od funkcji.
nazwa_funkcji powinna by¢ krótka i odzwierciedla¢ jej dziaªanie.
15patrz. 8, str. 9
8 ANALOGIA ONTOLOGICZNA 9
lista argumentów w postaci typ_zmiennej nazwa_zmiennej. Lista ta mo»e by¢ pu-
sta. Przykªadowo: funkcja podajWiek() nie potrzebuje »adnych danych z poza instancji
klasy Pies. Jednak, na przykªad, by kogo±, wpu±ci¢ pies musi wiedzie¢, kogo wpuszcza
(czyli musi mie¢ dane z poza zakresu klasy pies), wi¦c osob¦ do wpuszczenia podaje si¦
jako argument funkcji wpu±¢DoDomu(Osoba kto±). Je±li jest to odpowiednia osoba, jest
wpuszczana, je±li nie, to jest np. zjadana.
Czytelnik mo»e spyta¢, po co sprawdza¢ typ argumentu? Otó» je±li ka»emy psu wpu-
±ci¢ do domu np. Sprawiedliwo±¢, trójk¡t, czy liczb¦ `2', to popeªniamy bª¡d logiczny. Jest
chyba oczywiste, »e pies mo»e wpuszcza¢ do domu tylko byty materialne. W programie
ma to odzwierciedlenie poprzez sprawdzanie typu zmiennej.
8 Analogia ontologiczna
Obiekt to przedmiot. Twierdzenie to przyjmujemy na zasadzie aksjomatu, bowiem to
w nim analogia jest ufundowana.
Klasa to idea. Wida¢ to chyba do±¢ jasno. Klasa posiada wszystkie cechy wspólne jej
instancjom.
Metoda to cecha. Tutaj trzeba chyba powiedzie¢ wi¦cej. Mo»na zapyta¢ dlaczego
cechami nie s¡ metody oraz zmienne skªadowe. Jest tak, poniewa» dobry programista
chowa wszystkie zmienne do wn¦trza klasy, wi¦c s¡ one niewidoczne z poziomu innych
klas w programie, czyli nie s¡ cechami. Ponadto zmiennym skªadowym kasy nadamy
troch¦ inne znaczenie w nast¦pnej cz¦±ci pracy.
8.1 Wnioski z analogii
Postaram si¦ teraz wyeksploatowa¢ nasz¡ analogi¦, pozostan¡ pewne bardziej zªo»one
problemy, które rozwi¡»emy w nast¦pnych sekcjach.
Substrat to, co pozostanie z przedmiotu po odj¦ciu wszystkich jego cech. W przypadku
komputera s¡ to zmienne, czyli dane które niesie ze sob¡ przedmiot. Poniewa» s¡ to
dane odarte z kontekstu (kontekst to sposób przetwarzania danych, czyli metody),
jest to po prostu ci¡g zer i jedynek � materia prima komputera. Materia prima to
`to, co nie jest jakie±', a jak wykazywali±my16 pami¦¢ komputera ma t¦ wªasno±¢
»e, nie jest jaka±.
Istnienie Twierdziªem »e wielk¡ wad¡ ontologii jako takiej jest pozostawienie poj¦cia
istnienia niezde�niowanym. Przedstawi¦ zadowalaj¡c¡ de�nicj¦ istnienia w termi-
nach j¦zyka programowania, ale nie b¦dzie ona przekªadalna na terminy spoza tego
j¦zyka, czyli nie pomo»e nam w »aden sposób zde�niowa¢ tego terminu dla naszego
±wiata. De�nicja ta brzmi tak:
16sekcja 3.1
8 ANALOGIA ONTOLOGICZNA 10
Istnieje tylko to, dla czego zarezerwowana jest pami¦¢.
De�nicja ta jest chyba adekwatna, postaramy si¦ j¡ jednak uzasadni¢. Uzasadniamy
twierdzenie Istnienie ⇔ Zarezerwowana pami¦¢
Uzasadniamy Istnienie ⇒ Zarezerwowana pami¦¢: je±li co± istnieje w komputerze
to zajmuje pami¦¢ � ka»dy program, ka»da dana musz¡ gdzie± w komputerze
przebywa¢.
Uzasadniamy: Istnienie⇐ Zarezerwowana pami¦¢: ka»dy fragment zarezerwowanej
pami¦ci nale»y do jakiego± programu (czyli co± w nim jest).
To»samo±¢ W programowaniu bardzo ªatwo sprawdzi¢, czy dwa przedmioty s¡ tym
samym przedmiotem. Sprawdzenie to polega na sprawdzeniu adresów tych obiektów
w pami¦ci, je±li s¡ one to»same17, to te dwa obiekty s¡ tym samym obiektem18
Paradoksy cech Jednym z paradoksów teorii idei jest to »e idea ma pewne cechy, ale
te cechy nie maj¡ »adnych konkretnych warto±ci. (Pies mo»e by¢ rudy lub czarny,
lecz idea Psa nie mo»e mie¢ »adnego konkretnego koloru).
Powszechnik (. . . ) jest to przedmiot, który posiada wszystkie cechy wspól-
ne ogóªowi przedmiotów swego gatunku, a nie posiada »adnej z cech,
które nie byªyby wspólne tym przedmiotom. Zauwa»my nast¦pnie »e, »e
o ka»dym przedmiocie konkretnym jest prawd¡ to, i» ma on jak¡± wªa-
sno±¢ swoist¡ (. . . ) Zatem cecha posiadania cechy swoistej jest wspólna
17Uwagi, na któr¡ wpadªem dopiero po przerobieniu identyczno±ci w czasie.Dotyczy to oczywi±cie to»samo±ci przedmiotu w jednej chwili czasu. Przykªadowo w C++ (w Javie
jest to niewykonalne), mo»na skasowa¢ obiekt i zapisa¢ na jego miejscu inny, wtedy nasze `chwilowe'kryterium dalej wskazywaªoby »e te dwa obiekty s¡ to»same. Jednak jest to jedyne kryterium to»samo±ci(bycia tym samym), jakie mo»emy mie¢ w samym j¦zyku programowania. Nie da si¦ go ogólnie rozszerzy¢na identyczno±¢ w czasie � równie» w Javie. Przykªadowo, dla instancji niektórych klas, mo»na zmieni¢wªasno±ci danej instancji nie kasuj¡c obiektu � b¦dziemy mieli wtedy obiekt który jest tym samym
obiektem, ale nie takim samym.Istniej¡ te» wsparte w samym j¦zyku metody sprawdzania czy obiekty s¡ takie same. Przykªadowo
mo»na najpierw porówna¢ czy oba przedmioty nale»¡ do tej samej klasy (porównamy w ten sposóbmetody) a nast¦pnie porówna¢ czy wszystkie skªadowe maj¡ te same warto±ci . C++ takie porównaniewykonuje automatycznie. W Javie jest ono bardzo ªatwe do automatycznego wygenerowania. (Metod¦t¡ nale»y odrobin¦ przystosowa¢, by miaªa oba zastosowanie w prawdziwym programie, tj. by dziaªaªaona dla wska¹ników, ale przystosowanie to nie zmienia nic w istocie problemu).Ogólnie stosuje si¦ metody mieszane (tutaj mówi¦ ju» nie o samym paradygmacie, a o praktycznych
metodach pisania programu). Na przykªad sprawdzaj¡c to»samo±¢ obiektów, sprawdza si¦ ich identy�-kator, który ma by¢ unikalny. Przykªadowo s¡d, chc¡c sprawdzi¢ czy na rozpraw¦ nie przyszedª oszustnie sprawdza kodu DNA (bo jest to operacja czasochªonna i droga), a tylko numer PESEL (unikalnyidenty�kator).Mo»liwe »e, jak w programowaniu, w ontologii nie ma jednego, sensownego, sposobu sprawdzania
to»samo±ci w czasie. A gdy nie ma jednego prawidªowego sposobu, winni±my szuka¢ sposobu wygodnego.18Dwie uwagi: jest tak w `zwykªych' programach, s¡ pewne aplikacje które tego wymogu nie speªniaj¡
np. aplikacje rozproszone dziaªaj¡ce na wielu komputerach z których ka»dy ma swoje repozytoriumdanych i które to repozytoria si¦ nakªadaj¡, tj. ten sam obiekt jest w kilku maszynach (ale problemrozproszonego przetwarzania danych, jest w ogóle, jednym z bardzo trudnych dziaªów informatyki); jestte» mo»liwe »e w ró»nych chwilach t¦ sam¡ pami¦¢ zajmuj¡ dwa obiekty (problem ten jest ªatwy dorozwi¡zania, przykªadowo w Javie w ogóle go nie ma.)
8 ANALOGIA ONTOLOGICZNA 11
wszystkim przedmiotom danego gatunku. St¡d wniosek, powszechnik ze
wzgl¦du na dany gatunek musi tak»e posiada¢ cech¦ posiadania cechy
swoistej. (. . . ) znaczy to, »e powszechnik ma pewn¡ cech¦ swoist¡, której
nie posiada »aden przedmiot, a to ju» jest sprzeczne z powy»sz¡ de�nicj¡.
Nasza analogia dobrze rozwi¡zuje ten paradoks, mianowicie nie jest on na jej grun-
cie »adnym paradoksem. Klasa nie posiada »adnych konkretnych cech. Nawet je±li
klasa pies posiada funkcj¦ podajKolorSier±ci, to na klasie tej funkcji nie wywo-
ªamy, do tego trzeba konkretnej instancji. Jest tak poniewa» metody klasy operuj¡
na zmiennych konkretnego obiektu, a dla samej klasy nie przydziela si¦ pami¦ci
na zmienne. Klasa ma cechy, jednak posiada je inaczej ni» jej instancja. Mo»na
powiedzie¢, »e klasa posiada sloty na cechy, pewne miejsca, gdzie te cechy mog¡
`wpa±¢'.
Istnienie cech Cechy istniej¡. Uto»samili±my cechy z metodami i zde�niowali±my ist-
nienie jako zajmowanie pami¦ci. Metody zajmuj¡ pami¦¢19, zatem istniej¡.
Cechy idei samych Jeden z powa»niejszych zarzutów co do teorii idei20 da si¦ stre±ci¢
w sªowach:
Platon podkre±laª, »e byt idei jest doskonaªy: tzn. s¡ one wieczne i nie
podlegaj¡ »adnym zmianom, nie mog¡ by¢ unicestwione. Z drugiej jednak
strony np. czªowiek w ogóle powinien posiada¢ takie cechy jak ±miertel-
no±¢ i zmienno±¢ (. . . ). Jak wi¦c pogodzi¢ go z wieczno±ci¡ i niezmien-
no±ci¡ czªowieka idealnego. [5]
Paradoks ten przeformuªujemy tak: Idea posiada cech¦ bycia wieczn¡, przedmiot
posiada wszystkie cechy idei, wi¦c przedmiot jest wieczny.
W naszej semantyce nie jest to paradoks. Bowiem klasa nie posiada cechy bycia
wieczn¡. Klasa jest wieczna21,22 ale nie posiada cechy (w ±wietle naszej de�nicji
tego poj¦cia) �bycia wieczn¡�. Rozwi¡zanie to jest podatne na krytyk¦, bowiem
zawsze mo»na atakowa¢ sam¡ de�nicj¦ cechy. Zarzut ten odepr¦ w nast¦pnej cz¦±ci
pracy.
19Wszystko w komputerze jest w pami¦ci, metody w postaci polece« dla procesora te».20w poj¦ciu T. Bigaja21Bowiem nie zmienia si¦ w trakcie wykonania programu � wi¦c z punktu widzenia samego programu
jest wieczna.22Jest to cecha C++, natomiast s¡ j¦zyki programowania gdzie klasy mog¡ powstawa¢ w trakcie
wykonania programu, mog¡ gin¡¢, mog¡ pojawia¢ si¦ nowe klasy, a nawet klasy mog¡ si¦ zmienia¢.Uwaga ta nic nie zmienia moim argumencie, bowiem wskazuje tylko »e idee nie musza by¢ wieczne.Jednak pierwotny argument (wieczno±¢ nie jest cech¡) jest ogólniejszy.
9 O CECHACH IDEI 12
9 O cechach idei
Problem zarysowany w poprzedniej cz¦±ci jest bardzo skomplikowany, a jego rozwi¡-
zanie brzmi bardzo przewrotnie, dlatego te» postanowiªem zarysowa¢ je tu w bardziej
±cisªej formie.
9.1 Teza
Aksjomat Ka»dy przedmiot ma cechy immanentne i akcydentalne.
Twierdzenie I Rzeczywisto±¢ ma wiele poziomów. Trzema z nich s¡: ±wiat idei, ±wiat
form (poj¦¢) i ±wiat materialny. W ±wiecie materii mo»na ufundowa¢ ±wiat wiele
±wiatów informacji23.
Twierdzenie II Poziomy te s¡ zale»ne od siebie, ale w ten sposób »e cechy immanentne
poziomu ni»szego s¡ de�niowane przez cechy akcydentalne poziomu wy»szego.
Wiem, »e twierdzenia te brzmi¡ w¡tpliwie, ale postaram si¦ wykaza¢ ich prawdziwo±¢,
oraz pokaza¢, jak one wypªywaj¡ z naszej nowej semantyki.
9.2 Analogia informatyczna
Klasy maj¡ pewne cechy akcydentalne, (tj. funkcje i zmienne24), maj¡ te» pewne
cechy immanentne, np. to, »e w czasie wykonania pozostaj¡ niezmienione, to »e maj¡
okre±lon¡ budow¦, okre±lon¡ skªadni¦ i inne. Cechy akcydentalne klas de�niuj¡ cechy
immanentne ich instancji, natomiast ich cechy immanentne25 nie maj¡ »adnego znaczenia
dla obiektów.
Zmienne i metody s¡ akcydentalne dla klas, bowiem zale»¡ od kaprysu programisty,
natomiast nie da si¦ zmienia¢ klas w »aden sposób podczas wykonania programu.
T¦ analogi¦ mo»na ci¡gn¡¢ dalej. Zrobi¦, to by wykaza¢, »e twierdzenie to jest zasadne
dla wielu poziomów rzeczywisto±ci.
±wiat materialny cechy immanentne: staªa przenikalno±ci elektrycznej, pr¦dko±¢ ±wia-
tªa, masa elektronu (ogólnie wszystkie staªe i prawa �zyki)
cechy akcydentalne Istnieje w nim pewien komputer PC (mój komputer).
23�wiatem informacji b¦dzie komputer (rozumiany nie jako maszyna, ale jako np. system operacyjny),czy ksi¡»ka (rozumiana jako fabuª¡, a nie `zestaw kartek'), istnienie obu tych ±wiatów zale»y od pewnychkonkretnych warunków ±wiata materialnego � w pierwszym przypadku pr¡du w gniazdku, w drugimczytelnika. S¡ one o tyle niezale»ne od ±wiata materialnego, »e nie kieruje prac¡ komputera manipuluj¡celektronami na nó»kach procesora, a pisz¡c program.
24i inne które, nie s¡ wspomnienie w tej pracy.25Mam tu na my±li to »e gramatyka konkretnego j¦zyka nie wpªywa na zachowanie obiektów w nim
napisanych, tj. mo»na skonstruowa¢ takie same obiekty w j¦zyku o innej gramatyce. Przykªadowo dlaoznaczenia obiektu staªego w C++ u»ywa si¦ sªowa const a w Javie � final, s¡ to cechy immanentnedla j¦zyka, ale nie maj¡ one wpªywu na to »e obiekt ten jest rzeczywi±cie niezmienny w trakcie wykonaniaprogramu.
9 O CECHACH IDEI 13
O ile pr¦dko±¢ ±wiatªa nie mo»e (w ±wietle praw �zyki) si¦ zmieni¢, o tyle mojego
komputera kiedy± nie byªo, i kiedy± go nie b¦dzie.
±wiat mojego komputera Cechy immanentne jest stworzony w standardzie PC.
�wiat stanowi fundacj¦ komputera, ale komputer jako ukªad elektroniczny jest
zasadniczo niezale»ny od ±wiata (jak próbowaªem wykaza¢ w sekcji 3.1).
Ukªad elektroniczny na pewnym poziomie musi by¢ ufundowany w �zyce (tylko
wtedy dziaªa), ale kiedy ju» dziaªa nie interesuje nas dlaczego i na jakiej zasa-
dzie. Wiedza ta jest potrzeba w fazie projektowania samego ukªadu, ale nie przy
wykorzystywaniu ukªadu w dalszej pracy.
Inaczej mo»na to uargumentowa¢ tak: skoro warunkiem koniecznym istnienia ±wiata
informatycznego jest dziaªaj¡cy komputer, to warunkiem dostatecznym dla dziaªa-
nia komputera jest istnienie w nim ±wiata, a poniewa» mamy warunek dostateczny
dziaªania komputera, nie interesuj¡ nas inne warunki dostateczne, w szczególno±ci
nie interesuje nas ±wiat materialny.
cechy akcydentalne Zainstalowano na nim system Linux26.
±wiat systemu operacyjnego cechy immanentne: jest to system Linux.
Podobnie jak poprzednio, z punktu widzenia systemu operacyjnego jest bez zna-
czenia, na jakim komputerze jest on zainstalowany (mógªby by¢ zainstalowany na
jakim± Solarisie, czy na PowerPc27). Oczywi±cie system zainstalowany na PowerPc
ma troch¦ inne komponenty ni» ten na PC, ale z punktu widzenia u»ytkownika i
programisty jest to bez znaczenia.
cechy akcydentalne jest na nim, pewien konkretny, kompilator C++.
±wiat programu C++ cechy immanentne Jest to program w C++ (czyli ma pewna
skªadni¦, pewne mo»liwo±ci i ma te» wiele innych cech).
cechy akcydentalne program obsªuguje baz¦ danych.
±wiat programu (w u»yciu) cechy immanentne Jest to program obsªuguj¡cy baz¦ da-
nych.
Uwaga! Dla u»ytkownika nie ma najmniejszego znaczenia, w jakim j¦zyku progra-
mowania jest on napisany, czyli znowu cechy immanentne wy»szego poziomu nie
maj¡ dla nas znaczenia na ni»szym poziomie
cechy akcydentalne Jest na nim konkretna baza danych.
(. . . )
Tych poziomów ±wiata jest bardzo du»o28.26Akurat to jest faªsz, ale uªatwia mi ono argumentacj¦.27S¡ to inne standardy sprz¦tu komputerowego28W istocie niesko«czenie wiele, bowiem mo»emy u»y¢ tzw. emulatora, czyli programu który emuluje
jeden system operacyjny w innym systemie. Wtedy mo»emy ustawia¢ system operacyjny na systemieoperacyjnym, na emulowanym postawi¢ kolejny i tak dalej.
10 PLURALIZM A EWENTYZM 14
9.3 O Plotynie
Je±li czytelnik nie daª si¦ przekona¢ moim nowoczesnym argumentom, mo»e da si¦
przekona¢ Plotynowi. Jego ±wiat te» byª podzielony na pªaszczyzny.
Cechy immanentne (wªa±ciwie jedna jego cecha) jednego nie maj¡ wpªywu na Umysª.
Jedyn¡ cech¡ immanentn¡ jednego jest to, »e jest jedno±ci¡. Umysª nawet nie widzi
jednego jako jedno. Cech¡ akcydentaln¡ jednego (kªadziono nacisk na to, »e jest to cecha
akcydentalna jednego) jest to, »e tworzy.
Podobnie ma si¦ rzecz z Umysªem. Cech¡ immanentn¡ Umysªu jest tom »e my±li,
akcydentaln¡, »e tworzy.
Plotyn pisaª, »e ostatni¡ granica tworzenia jest materia, w mojej pracy próbuj¦ wy-
kaza¢ mi¦dzy innymi to, »e si¦ myliª.
9.4 Rozwi¡zanie problemu
Mam nadziej¦, »e powy»szy obraz stanowi dobre uzasadnienie Twierdze« I i II. A
skoro mamy uzasadnione Twierdzenie II, problem wieczno±ci idei jest rozwi¡zany. Bo-
wiem to, »e idea jest wieczna stanowi jej cech¦ immanentn¡, wi¦c nie maj¡c¡ wpªywu na
±wiat przedmiotów (zatem, w szczególno±ci, na same przedmioty).
9.5 Wyja±nienie, czyli dlaczego trzeba przej±¢ tak dªug¡ drog¦, »eby
doj±¢ do tego rozwi¡zania
Po prostu ±wiat jest zbyt skomplikowany, by zobaczy¢ co± takiego wªa±nie w nim �
musieli±my odwoªa¢ si¦ do prostszego modelu. Ponadto swiat ma raptem kilka warstw
� ±wiat idei, ±wiat poj¦¢, i ±wiat materialny. Wi¦kszo±¢ �lozofów jednak wyró»nia tylko:
±wiat idei (lub ±wiat poj¦¢) i ±wiat materialny. Ci¦»ko dowodzi¢ twierdze« dotycz¡cych
relacji pomi¦dzy warstwami ±wiata, gdy s¡ dwie warstwy w ogóle (wtedy nie s¡ to twier-
dzenia a fakty jednostkowe).
10 Pluralizm29 a ewentyzm
Oba te rozwi¡zania s¡ w istocie poprawne, jedynym warunkiem, który pozwala roz-
strzygn¡¢ na korzy±¢ jednego z nich, jest wygoda stosowania.
10.1 Analogia informatyczna
W naszej analogii Pluralizm jest zde�niowany w sekcji 8, a ewentyzm twierdzi »e
istniej¡ tylko zdarzenia30. Ró»nic¡ wzgl¦dem oryginalnego ewentyzmu Augustyka jest to,
29U»ywam terminu prof. Augustynka.30Wersji ewentyzmu, która twierdzi, »e zdarzenia istniej¡ bardziej ni» przedmioty nie mog¦ rozwa»a¢
jako »e twierdz¦, »e w tym wypadku istnienie jest predykatem zero-jedynkowym.
11 O RODZAJACH CECH 15
»e nie chodzi o zdarzenia w czasoprzestrzenne, ale w troch¦ innym sensie. By wykaza¢
ró»nic¦, musz¦ poda¢ kilka danych technicznych.
Procesor dziaªa w nast¦puj¡cy sposób: ma kilka wej±¢ i kilka wyj±¢. Co okre±lony czas,
zwany taktem, sprawdza stany napi¦¢ na wej±ciach i ustala na wyj±ciach stany okre±lone
poprzez stany wej±ciowe. Dla przykªadu31: wyobra¹my sobie procesor kalkulatora. Ma
on trzy wej±cia i jedno wyj±cie � na pierwszym jest podawana jedna liczba, na drugim
druga, a trzecie wskazuje operacj¦ do wykonania. Teraz ustawiamy na wej±ciach liczby
10 i 20 a na wej±ciu kontrolnym sygnaª dodawania. Na wyj±ciu pojawi si¦ liczba 30.
W nowym ewenty¹mie zdarzeniem b¦dzie ka»dy takt procesora, rzecz¡ b¦dzie zbiór
taktów, w których procesor przetwarza wªa±nie t¦ rzecz, a cech¡ zbiór taktów, w których
przetwarza wywoªanie metody odpowiadaj¡cej danej cesze. Opis ten jest równowa»ny
opisowi z sekcji 8.1, gdy» pomi¦dzy obiektami zde�niowanymi na oba sposoby istnieje
relacja 1-1, czyli ka»demu obiektowi zde�niowanemu w jeden sposób odpowiada dokªad-
nie jeden obiekt zde�niowany w drugi sposób. Te opisy jednak nale»¡ do troch¦ innych
rzeczywisto±ci: ewentyzm nale»y do ±wiata kodu wykonywalnego (polece« dla procesora),
a pluralizm do ±wiata j¦zyków wysokiego poziomu. Cho¢ oba adekwatnie opisuj¡ rzeczy-
wisto±¢ � jeden robi to w sposób przyst¦pny czªowiekowi, a drugi nie. Od j¦zyków
niskiego poziomu powoli si¦ odchodzi, a kod wykonywalny jest najni»szym mo»liwym
poziomem.
10.2 Odniesienie do ontologii
Ewentyzm u»ywa terminów ze ±wiata szczególnej teorii wzgl¦dno±ci. Poj¦ciem pod-
stawowym jest zdarzenie. Pluralizm natomiast u»ywa terminów ze ±wiata poj¦¢, de�niuje
jedne poj¦cie przez inne. Teorie s¡ równowa»ne, je±li mo»na ewentystycznie zde�niowa¢
dowolny pluralistycznie rozumiany przedmiot. A w sposób oczywisty jest to mo»liwe �
bowiem wszystkiemu przypisany jest jednoznacznie pewien zbiór zdarze«.
Jednak, tak jak w analogii informatycznej, ªatwo jest posªugiwa¢ si¦ poj¦ciami plu-
ralizmu, natomiast posªugiwanie si¦ poj¦ciami ewentyzmu jest prawie niewykonalne.
11 O rodzajach cech
Nast¦pny fragment b¦dzie prób¡ odbicia pewnego argumentu, jak te» zarysowania
pewnego innego problemu teorii ontologii zawieraj¡cej cechy.
11.1 Analogia informatyczna
Zgodzili±my si¦, »e cechy to metody klasy. Nale»y teraz bardzo silnie odró»ni¢ istnie-
nie metody oraz warto±¢ przez ni¡ zwracan¡. W naszej ontologii ksztaªt mo»e by¢ cech¡
31Przykªad ten jest technicznie nieadekwatny � bowiem procesor kalkulatora miaªby kilkadziesi¡twej±¢, z tego pierwszych kilkana±cie tworzyªoby pierwsz¡ liczb¡ zapisan¡ w systemie binarnym.
11 O RODZAJACH CECH 16
(bowiem rozs¡dnym jest stworzenie funkcji zwracaj¡cej ksztaªt), natomiast kulisto±¢ nie,
bowiem ksztaªt kulisty jest wynikiem zwracanym przez funkcj¦ podaj¡c¡ ksztaªt.
Tak samo mo»liwo±¢ posiadania okre±lonej temperatury jest cech¡, natomiast kon-
kretna temperatura ju» ni¡ nie jest.
Mo»na te» powiedzie¢ inaczej. Obie te rzeczy s¡ cechami, ale w innym sensie. S¡ to
dwa ró»ne aspekty cech. Bowiem jest tak, »e posiadanie jakiej± temperatury jest cech¡
immanentn¡ natomiast posiadanie konkretnej akcydentaln¡. W ka»dym razie nale»y bar-
dzo uwa»nie rozró»ni¢ te poj¦cia, poniewa» podstawiaj¡c jedno za drugie popeªnia si¦
bª¡d.
Dalej w tek±cie, gdy b¦d¦ potrzebowaª rozró»nienia, na poj¦cie owej cechy immanent-
nej b¦d¦ u»ywaª symbolu cecha1, natomiast cech¦ w drugim znaczeniu b¦d¦ oznaczaª
cecha2.
11.2 O Spinozie
Wydaje mi si¦, »e podobn¡ rzecz miaª na my±li Spinoza pisz¡c o atrybutach i pobu-
dzeniach substancji. Atrybutem substancji byªa np. jej przestrzenno±¢, a pobudzeniem
konkretny przestrzenny obiekt. Oczywi±cie jego teoria dotyczyªa jedynej rzeczy, która
w jego poj¦ciu istniaªa � substancji, a ja t¦ teori¦ rozci¡gam na ka»dy obiekt. Tym
niemniej podobie«stwo jest.
11.3 Odparcie argumentu
Argument przytaczam z artykuªu T. Kotarbi«skiego:
Cz¦sto sªyszymy, »e cechy przysªuguj¡, albo »e cechy tkwi¡ w rzeczach. Có»
to za przysªugiwanie? Mówi si¦ tak, lecz jako± przeno±nie, zast¦pczo. Wszak
okr¡gªo±¢ nie peªni wzgl¦dem kul »adnych posªug. . . Ani te» nie tkwi w kulach
jak gwó¹d¹ w ±cianie.[6]
Wida¢ tutaj ju» doskonale, gdzie tkwi pozorna sprzeczno±¢ poj¦cia idei. Kr¡gªo±¢
nie jest cech¡ (przynajmniej nie w moim rozumieniu), wi¦c nie tkwi w przedmiocie.
Natomiast jego przestrzenno±¢, czyli mo»liwo±¢ posiadania ksztaªtu � owszem. Chyba
wszyscy si¦ zgodz¡, »e przestrzenno±¢ tkwi w przedmiocie.
11.4 Pewien problem
Pierwszym problemem jest to, »e by `odbi¢' pewien argument powoªaªem do »ycia
jedno poj¦cie � cech¦2, czyli w naszym przykªadzie, konkretny ksztaªt. Mo»na si¦ przed
moim argumentem broni¢, twierdz¡c »e »aden przedmiot nie jest dokªadnie kolisty, czyli
»e kolisto±¢ jest universale pustym. I to powoduje problemy � bowiem dotyka to pro-
blemu wieloznaczno±ci terminu universale (rozró»nienia pomi¦dzy universale w sensie
12 DZIEDZICZENIE, CZYLI NOWA HIERARCHIA IDEI 17
zbioru cech1, a universale w sensie przedmiotu o ustalonej cesze2). Problemem tym si¦
zajm¦ po rozwini¦ciu naszej programistycznej ontologii o jeszcze jedno poj¦cie.
12 Dziedziczenie, czyli nowa hierarchia idei
W naszej ontologii brakuje jeszcze jednej rzeczy � plato«skiej hierarchii idei. Wszy-
scy meta�zycy, którzy postulowali istnienie universale, zakªadali istnienie pewnej hierar-
chii. C++ powstanie tej hierarchii umo»liwia. Przedstawi¦ teraz rozumowanie, które do
tego doprowadziªo.
Wydawaªoby si¦, »e universale czªowieka i ssaka s¡ jako± powi¡zane. W rozumieniu
dystrybutywnym cech s¡ powi¡zane w ten sposób, »e ka»dy czªowiek jest z ssakiem (lu-
dzie s¡ podzbiorem ssaków). Platon powiedziaªby, »e idea czªowieka partycypuje w idei
ssaka. Wszystkie te rozumienia mieszcz¡ si¦ poj¦ciu dziedziczenia. Jest to poj¦cie progra-
mistyczne wyra»aj¡ce relacj¦ klas bardzo podobn¡ do powi¡zania idei ssaka i czªowieka.
Do poj¦cia dziedziczenia doprowadziªy dwa oddzielne problemy:
Problem wspólnego interfejsu, czyli problem wspólnych cech. Programista chciaªby
czasem potraktowa¢ czªowieka jak ssaka, albo Boeinga 656, jako samolot. Nie mo»e
tego zrobi¢ ot tak po prostu, bowiem s¡ to ró»ne klasy. Mo»e natomiast zde�niowa¢
je tak by byªo to mo»liwe.
Powtórne wykorzystywanie kodu.
Zaªó»my, »e mamy klas¦ punkt i »e bardzo napracowali±my si¦, aby zde�-
niowa¢ t¦ klas¦ ze wszystkimi metodami skªadowymi. Wreszcie wszystko
mamy. I oto w programie wynika konieczno±¢ u»ycia dodatkowej klasy
� podobnej do tej, z tym, »e ró»ni¡cej si¦ w kilku szczegóªach.
Czy trzeba wobec tego pisa¢ klas¦ od nowa? Czy nie mo»na po prostu
powiedzie¢ �Chc¦ mie¢ klas¦ tak¡, jak tamta, z maªymi ró»nicami. Oto
te ró»nice. . . �[8]
Mo»na, t¦ mo»liwo±¢ zapewnia mechanizm dziedziczenia.
12.1 Detale techniczne
Nie b¦d¦ ju» Czytelnika m¦czy¢ skªadni¡ dziedziczenia (nie jest ona istotna). Wa»ny
jest natomiast inny problem, i by go rozwi¡za¢, b¦d¦ go musiaª jeszcze pom¦czy¢ opo-
wiadaniem o dziedziczeniu.
Dziedziczenie W niektórych przypadkach, klasa b¦dzie posiada¢ tzw. �podklas¦�, czyli
jej bardziej wyspecjalizowan¡ wersj¦. Dla przykªadu, klasa Pies b¦dzie miaªa pod-
klasy zwane Collie, Chihuahua i GoldenRetriver. W tym przypadku Lessie by-
ªaby instancj¡ podklasy Collie. Podklasa dziedziczy wszystkie wªasno±ci i metody
12 DZIEDZICZENIE, CZYLI NOWA HIERARCHIA IDEI 18
ze swojej klasy-matki, jak równie» mo»e doda¢ swoje wªasne. Zaªó»my »e klasa
pies posiada metod¦ szczekaj() i wªasno±¢ kolorSier±ci ka»da z podklas b¦-
dzie miaªa te przymioty. (. . . )Ka»da podklasa mo»e zmieni¢ odziedziczone przy-
mioty. Dla przykªadu podklasa Collie mo»e domy±lnie mie¢ kolor sier±ci wªa±ciwy
dla psów Collie (br¡zowo-biaªe), a Chihuahua mo»e wykonywa¢ szczekanie wy»-
szym d¹wi¦kiem. (. . . ). Mo»e te» mie¢ metod¦ dr»yj(). [2, hasªo: Object-oriented
programming]
Jak widzimy, pewne wªasno±ci mog¡ by¢ zmieniane na poziomie podklas. Dlatego
te» (wracamy do przykªadu z kulisto±ci¡ tkwi¡c¡ w przedmiocie) mo»emy utworzy¢
podklas¦ Kuliste klasy Posiadaj¡ceKsztaªt, dla której funkcja podajKsztaªt b¦dzie
zwracaªa zawsze ksztaªt kulisty. Mo»emy jednak nie tworzy¢ takiej klasy i u»ywa¢ klasy
Posiadaj¡ceKsztaªt, z tym »e zawsze explicite, podawa¢ jej ksztaªt.
Wybieramy to co jest wygodniejsze. Wi¦kszo±¢ programistów wybierze utworzenie
klasy Kuliste, natomiast przy tworzeniu klasy Gruszkowate, czy
WKsztaªcieSto»ka�ci¦tegoWPoªowieWyskoko±ciPodK¡tem45Stopni zacznie si¦ zasta-
nawia¢ czy ma to sens.
Tutaj wªa±nie dotykamy pewnego problemu. Pewne klasy musimy mie¢: przykªadowo
je±li cokolwiek ma mie¢ ksztaªt to musimy stworzy¢ klas¦ Posiadaj¡ceKsztaªt. Klasy
Kuliste tworzy¢ nie musimy.
12.2 Analogia ontologiczna
Tak, jak wykryli±my dwuznaczno±¢ poj¦cia cecha, tak tra�amy na dwuznaczno±¢ po-
j¦cia universale (cho¢ to zdanie jest podatne na ewentualne zarzuty). Pewnym jest jednak
»e samo poj¦cie �poj¦cie� jest dwuznaczne. Widzimy bowiem »e pomi¦dzy posiadaj¡cym
ksztaªt w ogóle a posiadaj¡cym ksztaªt kolisty, zachodzi ta sama relacja, która zachodzi
pomi¦dzy posiadaj¡cym jak¡± temperatur¦ a posiadaj¡cym temperatur¦ 10◦C. A jednak
kulisto±¢ jest poj¦ciem, natomiast posiadanie temperatury 10 stopni nie jest.
Pewne poj¦cia s¡ niezb¦dne (po ich wyrugowaniu pewne zdania stawaªyby si¦ nie-
wyra»alne), inne natomiast nie. Przykªadowo zamiast mówi¢ �kulisty� mo»emy mówi¢
�posiadaj¡cy ksztaªt opisywany funkcj¡ x2 + y2 + z2 = a�. Nie robimy tak, bowiem jest
tonie wygodne. Natomiast samego poj¦cia ksztaªtu wyrugowa¢ si¦ nie da.
I teraz tu tkwi sedno ataków na poj¦cie cechy: o ile mo»na atakowa¢ posiadanie
cechy kulisto±ci, o tyle nikt przy zdrowych zmysªach nie zaatakuje tego, »e przedmioty
posiadaj¡ cech¦ przestrzenno±ci. A zauwa»my, »e je±li kto± atakowaª poj¦cie cechy, to
byªy to cechy2, nigdy cechy1. Gdyby kto± atakowaª poj¦cie cechy 2, zawsze pozostaje
nam argument z wygody. Wygodniej jest u»ywa¢ j¦zyka z tymi cechami.
O ile universale1s¡ immanentne, nieusuwalne i niezb¦dne, to istnienie universale2 jest
kwesti¡ umowy, j¦zyka.
13 ZAKO�CZENIE 19
13 Zako«czenie
Analogia informatyczna, ze wzgl¦du na swoj¡ prostot¦ i precyzj¦, wiodªa mnie w
miar¦ prost¡ ±cie»k¡ przez tak trudn¡ dziedzin¦, jak ontologia. Udaªo mi si¦ z niej wy-
ci¡gn¡¢ kilka silnych argumentów przeciw pogl¡dom z którymi si¦ nie zgadzam.
Jednak zapuszczanie si¦ w takie analogie kryje w sobie jedno niebezpiecze«stwo �
czasem mo»na zapomnie¢ o tym »e jest to wªa±nie analogia, a» analogia i tylko analogia.
Dlatego wªa±nie nie najlepiej ko«czyªy si¦ próby maria»u �lozo�i i �zyki, �lozofowie brali
�zyk¦ zbyt powa»nie, próbowali dostosowa¢ �lozo�¦ (która ma by¢ wieczna) do ci¡gle
zmiennej �zyki. Gdyby traktowali �zyk¦ tylko jako analogi¦ miaªoby to lepsze efekty. Jak
pisaªem we wst¦pie, sama analogia jest bezwarto±ciowa, trzeba jeszcze wyja±ni¢ dlaczego
analogia istnieje, wskaza¢ co daje nam u»ycie tej analogii. Wierz¦ »e w tej pracy udaªo
mi si¦ dokona¢ obu tych rzeczy.
14 APENDYKS I
14 Apendyks
Czyli rzeczy przydatne do zrozumienia pracy, acz do tego nie konieczne.
14.1 Cytat z �Thinking in C++�
Classes designed to �t the problem tend to express it better. This means
that when you write the code, you're describing your solution in the terms
of the problem space (�Put the grommet in the bin�) rather than the terms
of the computer, which is the solution space (�Set the bit in the chip that
means that the relay will close�). You deal with higher-level concepts and can
do much more with a single line of code.
The other bene�t of this ease of expression is maintenance, which (if
reports can be believed) takes a huge portion of the cost over a program's
lifetime. If a program is easier to understand, then it's easier to maintain.
This can also reduce the cost of creating and maintaining the documentation.
14.2 Wycinek ze strony z Wikipedii o programowaniu obiektowo orien-
towanym
Zamieszczam angielsk¡ wersj¦ artukuªu bardzo ob�cie cytowanego w sekcji 7
• Class � a class de�nes the abstract characteristics of a thing, including the thing's
characteristics (its attributes or properties) and the things it can do (its behaviors
or methods or features). For example, the class Dog would consist of traits shared
by all dogs, for example breed, fur color, and the ability to bark. Classes provide
modularity and structure in an object�oriented computer program. A class should
typically be recognizable to a non�programmer familiar with the problem domain,
meaning that the characteristics of the class should make sense in context. Also,
the code for a class should be relatively self�contained. Collectively, the properties
and methods de�ned by a class are called members.
• Object � a particular instance of a class. The class of Dog de�nes all possible dogs by
listing the characteristics that they can have; the object Lassie is one particular dog,
with particular versions of the characteristics. A Dog has fur; Lassie has brown�
and�white fur. In programmer jargon, the object Lassie is an instance of the Dog
class. The set of values of the attributes of a particular object is called its state.
• Method � an object's abilities. Lassie, being a Dog, has the ability to bark. So
bark() is one of Lassie's methods. She may have other methods as well, for example
sit() or eat(). Within the program, using a method should only a�ect one particular
object; all Dogs can bark, but you need one particular dog to do the barking.
14 APENDYKS II
• Message passing � "The process by which an object sends data to another object
or asks the other object to invoke a method."[3]
• Inheritance � In some cases, a class will have ±ubclasses,"more specialized ver-
sions of a class. For example, the class Dog might have sub-classes called Collie,
Chihuahua, and GoldenRetriever. In this case, Lassie would be an instance of the
Collie subclass. Subclasses inherit attributes and behaviors from their parent clas-
ses, and can introduce their own. Suppose the Dog class de�nes a method called
bark() and a property called furColor. Each of its sub-classes (Collie, Chihuahua,
and GoldenRetriever) will inherit these members, meaning that the programmer
only needs to write the code for them once. Each subclass can alter its inherited
traits. So, for example, the Collie class might specify that the default furColor
for a collie is brown�and�white. The Chihuahua subclass might specify that the
bark() method is high�pitched by default. Subclasses can also add new members.
The Chihuahua subclass could add a method called tremble(). So an individual
chihuahua instance would use a high�pitched bark() from the Chihuahua subclass,
which in turn inherited the usual bark() from Dog. The chihuahua object would
also have the tremble() method, but Lassie would not, because she is a Collie,
not a Chihuahua. In fact, inheritance is an "is-a»elationship: Lassie is a Collie.
A Collie is a Dog. Thus, Lassie inherits the members of both Collies and Dogs.
When an object or class inherits its traits from more than one ancestor class, it's
called multiple inheritance. This is not always supported, as it can be hard both
to implement and to use well.
• Encapsulation �� conceals the exact details of how a particular class works from
objects that use its code or send messages to it. So, for example, the Dog class
has a bark() method. The code for the bark() method de�nes exactly how a bark
happens (e.g., by inhale() and then exhale(), at a particular pitch and volume).
Timmy, Lassie's friend, however, does not need to know exactly how she barks.
Encapsulation is achieved by specifying which classes may use the members of an
object. The result is that each object exposes to any class a certain interface ��
those members accessible to that class. The reason for encapsulation is to prevent
clients of an interface from depending on those parts of the implementation that
are likely to change in future, thereby allowing those changes to be made more
easily, that is, without changes to clients. For example, an interface can ensure
that puppies can only be added to an object of the class Dog by code in that
class. Members are often speci�ed as public, protected and private, determining
whether they are available to all classes, sub�classes or only the de�ning class.
Some languages go further: Java uses the protected keyword to restrict access also
to classes in the same package, C# and VB.NET reserve some members to classes
in the same assembly using keywords internal (C#) or Friend (VB.NET), and Ei�el
14 APENDYKS III
allows one to specify which classes may access any member.
• Abstraction �� simplifying complex reality by modeling classes appropriate to the
problem, and working at the most appropriate level of inheritance for a given aspect
of the problem. For example, Lassie the Dog may be treated as a Dog much of the
time, a Collie when necessary to access Collie-speci�c attributes or behaviors, and
as an Animal (perhaps the parent class of Dog) when counting Timmy's pets.
• Polymorphism �� polymorphism is behavior that varies depending on the class in
which the behavior is invoked, that is, two or more classes can react di�erently to
the same message. For example, if a Dog is commanded to speak() this may elicit
a Bark; if a Pig is commanded to speak() this may elicit an Oink.
LITERATURA IV
Literatura
[1] Wikipedia po polsku http://en.wikipedia.org/
[2] Wikipedia po angielsku http://en.wikipedia.org/ Cytaty w tªumaczeniu wªa-
snym.
[3] �Sªownik j¦zyka polskiego� PWN dost¦pny w internecie pod adresemWydawnictwa.
[4] The Free Dictionary po anglelsku http://www.thefreedictionary.com/
[5] Tomasz Bigaj �Kªopoty z Abstraktami� w tego»: �Kwanty, liczby, abstrakty�, wy-
dawnictwo Semper
[6] Tadeusz Kotarbi«ski �Fazy rozwojowe konkretyzmu� w tego»: �Dzieªa wszystkie.
Ontologia, teoria poznania i metodologia nauk� Ossolineum 1993
[7] Bruce Eckel �Thinking in C++�, tomy I i II ze strony Autora � http://www.
mindview.net/Books/TICPP/ThinkingInCPP2e.html. Cytaty w tªumaczeniu wªa-
snym.
[8] Jerzy Gr¦bosz �Symfonia C++ Standard�, tomy I i II, wydawnictwo EDITION
2000, Kraków 2006
[9] Ian Steward �Liczby natury�, tªum. Michaª Tempczyk, wydawnictwo CIS, War-
szawa 1996