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