SADRŽAJ

1. УВОД ....................................................................................................................................................... 1

2. ОСНОВНИ КОНЦЕПТИ ОБЈЕКТНО ОРЈЕНТИСАНОГ ПРОГРАМИРАЊА ................................. 4

2. 1. Појам објеката (Object) ................................................................................................................... 4

2.2. Појам класе (Class) .......................................................................................................................... 5

2.3. Метода (Method) ............................................................................................................................... 6

2.4. Реализација концепта објеката и класа ......................................................................................... 7

2.5. Конструктори ................................................................................................................................... 8

2.6. Референтни објекат This ................................................................................................................ 11

3. НАПРЕДНИ КОНЦЕПТИ ОБЈЕКТНО ОРЈЕНТИСАНОГ ПРОГРАМИРАЊА ............................. 13

3.1. Веза између класа – has веза ......................................................................................................... 13

3.2. Угњеждене класе - Nesting ............................................................................................................ 14

3.3. Веза између класа "is a" . Наслеђивање (Inheritance) ................................................................. 15

3.4. Преоптерећивање метода – Гажење (Override) ........................................................................... 19

3.5. Запечаћена класа (метода) – Sealed .............................................................................................. 23

3.6. Апстрактна класа - Abstract........................................................................................................... 26

3.7. Интерфејси (interfaces) .................................................................................................................. 29

4. ОБЈЕКТНО ОРЈЕНТИСАНО ПРОГРАМИРАЊЕ ПОД WINDOWS ОПЕРАТИВНИМ

СИСТЕМОМ ............................................................................................................................................. 33

4.1. Појам кросплатформност (Cross-platform) .................................................................................. 33

4.2. Реализација кросплатформности са програмским јеѕиком Java ............................................... 34

4.3. Реализација кросплатформности са програмским јеѕиком C# .................................................. 35

4.4. Специфичности објектно орјентисаног програмирања везане за оперативни систем Windows

................................................................................................................................................................ 36

5. ЗАКЉУЧАК .......................................................................................................................................... 39

1

1. УВОД

Иако идеја о објектно орјентисаном програмирању датира још из периода од пре

двадесетак година, било је потребо скоро више од две деценије да постане оно што данас

представља, слободно можемо рећи, модну тенденцију у програмирању. Људи из Финске

су пре више од двадесет година осмислили овај концепт и направили чак и свој

програмски језик који је у потпуности био објектно орјентисан, али тада тај пројекат није

успео да заживи.

Шта је било пре? Оно што је сигурно обележило један значајан временски период

као програмерски концепт, то је тзв. процедурално програмирање. Почеци процедуралног

програмирања се везују за појаву процедура и функција.

Функција је метода која се позива по имену, којој се прослеђује одређен број

параметара у виду основних (предефинисаних) типова података и која враћа један,

повратни, податак такође у виду предефинисаног типа. Процедура би представљала

методу која има све карактеристике као и функција, а с разликом да не враћа никакву

повратну вредност. Постојао је један главни блок, који је заправо био једна процедура, и

велики број процедура и функција које би једна другу позивале. Тада се уводи и појам

глобалних променљивих.

Глобалне променљиве су оне које су се тицале на нивоу целог програма, а не само

једне процедуре, односно функције.

Следи пример кода који показује имплементацију концепта процедура и функција у

програмском језику Visual Basic.

2

Револуцију у програмирању представљају низови и матрице. Овим је просто било

омогућено да се програмира, тј. да се искористи рачунар у сврху алата којим се за мало

времена уради захтевна математичка операција која захтева велики број променљивих или

велики број итерација. Да није извршена имплементација математичких матрица у

програмерском свету у виду низова и матрица и требате написати код који ће израчунати

збир унетих нпр. 50 бројева код би изгледао овако. (Код је написан у програмском језику

PHP.)

Са концептом матрица, односно низова, овај код се смањује на:

Матрице и низови нису концепт који се појавио са процедуралним програмирањем,

али њихова имплементација не може да реши проблем који ће сада бити описан.

Замислимо једноставну картотеку корисника неког производа која се састоји од

информација које су заједно са типом података приказане у следећој табели.

Матрица, која се у програмирању сматра за више димензионални низ могла би да

буде решење у случају да су сви подаци о корисницима које чувамо истог типа, али шта

сада? Програмери су у оваквим ситуацијама морали да направе три низа где би у једном

3

чували информације у презимену и имену у дрогом о броју година и у последњем о

просечној плати.

Када програмер жели да добије све информације о к-том кориснику, да би добио

његово презиме и име он тражи к-ти податак из првог низа, за број година потребан му је

к-ти податак из другог низа и за просечну плату тако ће к-ти податак из последњег низа.

Оно што је дошло заједно са процедуралним програмирањем то је концепт структура који

решава овај проблем. Структура је податак који се састоји из више предефинисаних

типова података који описују исту.

За претходни проблем креирали би структуру која би се звала КОРИСНИК, и која

би садржала податке о презимену и имену, броју година и просечној плати, па би се

подаци о свим корисницима могли учитати не у три низа већ у један који би представљао

заправо низ структура КОРИСНИК. Следи декларација структуре КОРИСНИК написана у

програмском језику C++.

Имплементација структура као концепта је нешто на шта ће се уз извесно

проширење засновати концепт класе која је основа објектно орјентисаног програмирања.

4

2. ОСНОВНИ КОНЦЕПТИ ОБЈЕКТНО ОРЈЕНТИСАНОГ ПРОГРАМИРАЊА

2. 1. Појам објеката (Object)

Оно што свакако представља први, почетни корак, у коришћењу принципа објектно

орјентисаног програмирања, јесте свакако знање о томе шта је оно заправо. Да би

схватили шта је заправо овај концепт, најпре морамо дефинисати шта је то објекат, који у

ствари, представља основну јединицу којом се служимо са овим концептом. Са друге

стране, да би схватили шта је то објекат,потребно је овај проблем поистоветити са

природом.

Узмимо за пример један аутомобил у реалном свету. Нека буде то ауто који је

црвене боје, марке BMW, има петоро врата, 1800 кубика, петостепени мењаč, регистрацију

ЈА 234-201, ... Овај наш аутомобил такође може да врши неке операције као што су: да

стартује мотор, да се креће, да закочи, да упали светла,...

Наш аутомобил је заправо објекат у реалном свету и он је специфичан у односу на

све друге објекте јер има јединствену комбинацију вредности особина које га чине. Овај

објекат,описујемо тако што особинама као што су: боја, марка, број врата, ... додељујемо

вредности чија је комбинација јединствена тј. постоји само један овакав аутомобил,

односно само један овакав објекат. Објекат дакле, може бити било који предмет (целина)

посматрања. Неки објекти могу вршити функције као што је то случај био са

аутомобилом, а неки пак не морају, тј. не могу вршити никакву функцију. Пример за

овакав тип објекта је нпр. камен. Такође објекат може бити и нека апстрактна ствар као

што је нпр. уређење електрона. Када преведемо објекат на програмерски језик, имаћемо да

је он заправо: софтверски ентитет састављен од варијабли (променљивих, атрибута) и

метода. У овом контексту, атрибути би представљали вредности особина које описују

објекат, а методе би ако се вратимо на модел у стварном свету представљале

функционалност одређеног објекта. Сваки објекат с обзиром да је јединствен има своје

јединствено име које у програмерском свету представља референцу на меморијску

локацију на којој је уписан низ бајтова (битова) који га заправо чине.

5

2.2. Појам класе (Class)

Класа специфира карактеристике и понашања која деле сви чланови те класе.

Можемо заправо рећи да класа представља шему по којој се креирају одређени објекти.

Класа има дефинисане све особине (атрибуте) као и објекат с разликом да ниједна особина

нема одређену вредност у класи, јер је она заправо општи објекат.

Сетимо се нашег аутомобила за који смо рекли да је јединствен. Он припада класи

аутомобили. Класа аутомобили има особине: боја, марка, број врата, регистрација,..., али

нема дефинисане вредности ових особина. Наш аутомобил, који је заправо објекат класе

Аутомобили, као што смо већ рекли, има све ове особине, али има и њихове вредности.

Класа, као шема једног скупа истоветних објеката, тако ће има своје име и каже се да

објект припада класи која је именована (нпр. наш, горе описани, ауто припада класи

Аутомобили).

Овде смо објаснили основне елементе (објекат и класу) концепта објектно

орјентисаног програмирања, али у обрнутом редоследу. Наиме, у објектно орјентисаном

програмирању прво се дефинише класа са својим особинама и методама, па се затим за

сваку класу креира објекат са јединственим вредностима ових атрибута. Процес креирања

објекта од класе се назива процесом инстанцирања.

Значи ако наш аутомобил назовемо ауто1, рећи ћемо да је објекат ауто1 инстанца

класе Аутомобили. Следи графички приказ објеката ауто1 и ауто2 који се заправо

инстанце класе Аутомобили.

Следећа слика представља графичку интерпретацију класе Аутомобили.

6

Рекли смо да се структуре као концепт веома сличне концепту класа, односно

објеката. Такође смо рекли да све то важи, али уз напомену да постоји извесно

проширење. Оно се односи на то што класе за разлику од структура, могу да имају и

методе. Програмски језик C# омогућава коришћење и концепата класа, али и концепата

структура, где се структуре дефинишу чак и са могућношћу имања метода, тако да ово за

овај Microsoft-ов производ не важи.

2.3. Метода (Method)

Објашњавајући настанак концепта објектно орјентисаног програмирања,

споменули смо кроз процедурално програмирање концепт процедура и функција где смо

функцију дефинисали као методу која враћа једну повратну вредност простог типа

података, а процедуру пак као методу која не враћа никакву повратну вредност.

У објектно орјентисаном програмирању постоји само метода и она представља:

групу декларација и других наредби које извршавајуодређени задатак. Да би се тај задатак

обавио метода се може позвати више пута.

Оно што је основно за сваку методу то су елементи од којих је иста сачињена, а то

су:

- име – свака метода мора имати име по којој се иста позива.

- листу параметара (атрибута) који јој се прослеђују.

- тип повратне вредност.

- модификатор приступа – са којим се дефинише колико је могуће приступити

одређеној методи.

7

Наравно, у зависности од програмског језика методе могу имати и још неке

додатне елементе. Када се дефинише метода, онај први ред дефиниције, онај који говори о

вредностима ових наведених елемената, назива се сигнатура (потпис) методе. Објектно

орјентисано програмирање подразумева постојање само метода, а не процедура и

функција, што привидно може створити утисак да свака метода враћа неку од вредности,

али да ми, ако нам није потребна иста, је једноставно не користимо, међутим то није тако

(Иако је овакав трик сасвим у реду). Свака метода може:

1. вратити неки од типова података, (Овај податак не мора бити прост као што је то

случај са процедуралним програмирањем, већ може бити објекат било које класе,

па чак и структура у C#)

2. или не враћати никакву повратну вредност.

Ево како се ово реализује у програмском језику C#:

Пример методе која враћа површину површину правоугаоника, а истој се

прослеђује страница a и страница b. Претпоставимо да су странице a и b целобројног типа,

нпр. инт. (integer)

Ево и примера која не враћа никакву повратну вредност, већ само некој глобалној

променљивој повећава вредност за прослеђену целобројну вредност n.

2.4. Реализација концепта објеката и класа

Следи пример како се овај концепт у програмерској пракси реализује. Код је

написан у програмском језику JAVA. Пример за нашу класу Аутомобил која има поља:

боја, марка, ccm и методе крени и стани. У следећим табелама дати су описи за атрибуте и

методе наше класе:

8

Када смо дефинисали из којих делова се састоји наша класа следи написан код

којим се реализује ова замисао.

Креирали смо класу која представља сваки аутомобил у реалном светку. Питање

које се намеће је како сада од те класе инстанцирати објекат који ће заправо представљати

само један, јединствен, аутомобил. Да би се инстанцирао објекат класе, класа мора да има

дефинисан конструктор.

2.5. Конструктори

Конструктор је метода, тип методе, која стоји у класи и која има исто име као и

назив класе (у нашем случају то је Аутомобил), а којом се дефинише које су вредности

атрибута објекта који се инстанцира. Програмски језици попут JAVA-е обезбеђују тзв.

default конструктор, тј. подразумевани конструктор, тако да се и без дефинисања истог,

9

објекат класе може направити. Инстанцирање објекта са default конструктором

проузрокује то да се атрибути не мењају са креирањем објеката; они остају или default или

недефинисани ако то у класи нису.

Како смо рекли да је конструктор метода, он мора имати све елементе као што је то

случај са методом са изузетком да он нема повратну вредност. Иако он нема повратну

вредност не пише се за њега да је void, ово је зато што је конструктор посебна врста

методе. Дакле, конструктор мора имати:

1. име – име је исто као и име класе.

2. модификатор приступа – он мора бити јаван (public) ако се та класа може

инстанцирати.

3. параметре (атрибуте) који му се прослеђују.

Оно што је још занимљиво, је то да једна класа може имати више различитих

конструктора, који се исто зову, а који се разликују по томе што имају различит број

параметара који им се прослеђују. Ово омогућава концепт различитих потписа једне

методе (конструктора).

Програмски језик JAVA обезбеђује овај default конструктор, али у тренутку када се

креира неки други конструктор, овај подразумевани се укида те да би и он остао мора се

имплицитно дефинисати. У C# не постоји подразумевани конструктор те креирање бар

једног конструктора је обавезно. Ако нашој класи додамо конструктор коме се прослеђују

атрибути за боју, марку и ccm аутомобила, класа Аутомобил би изгледала овако:

10

Поставља се питање шта у конструктору представља this? Да би то било јасно,

потребно је најпре показати како се креира (инстанцира) објекат наше класе. Дакле,

хоћемо да направимо наш ауто о којем је било речи раније. Он се зове ауто1 и има

особине:

- боја: црвена

- марка: BMW

- ccm: 1800

Ако користимо наш конструктор, инстанцирање нашег аутомобила би изгледало:

Сада ћемо да креирамо други објекат, који се зове ауто2 и има особине:

- боја: бела

- марка: Мерцедес

- ccm: 2300

11

али користећи онај други, подразумевани, конструктор.

Следеће што би морали да радимо са нашим објектом да би био наш ауто је, да

променимо особине за боју, марку и ccm, што би било:

2.6. Референтни објекат This

Референтни објекат this представља тренути објекат са којим класа ради. Сваки

атрибут и свака метода може бити или static или instance.

Instance метода је она која се може позвати само ако је инстациран објекат класе

коме она припада. Са друге стране static метода је она која се може позивати без креирања

објекта класе. Значи да свака класа може имати методе које се односе баш за саму класу,

то су оне, static и оне које се односе на сам објекат, тј. instance. По аналогији може се

закључити шта су instance, а шта static атрибути. Подразумева се да је метода instance, а да

би се метода дефинисала као static потребно је да сигнатура исте садржи кључну реч

static.

Следи пример декларације класе по имену A која има static методу met1 и instance

методу met2, написан у програмском језику C#

12

Да би позвали методу met1 није потребно да креирамо објекат класе А, већ то

чинимо на следећи начин:

Са друге стране, да би позвали методу met2 која је instance, потребно је да

креирамо објекат класе А и да тек онда позовемо методу met2.

Поставља се питање како ће класа знати да ако се позове нека метода која је

instance и која је на пример void, а која треба да промени неки атрибут објекта који је тако

ће instance да то баш промени објекту класе који је корисник тражио. Одговор на питање

лежи у референтном објекту this којим се каже методи да мења атрибут тренутног објекта.

Сетимо се, ми креирамо објекат по имену ауто1 користећи наш конструктор који има три

атрибута. Код би у C# изгледао идентично:

Овим класа Аутомобил извршава следеће линије кода у конструктору:

Значи особине боја, марка и ccm се постављају објекту this класе Аутомобил што је

нашим позивом конструктора заправо објекат ауто1 класе Аутомобил.

13

3. НАПРЕДНИ КОНЦЕПТИ ОБЈЕКТНО ОРЈЕНТИСАНОГ ПРОГРАМИРАЊА

3.1. Веза између класа – has веза

Ако погледамо природу и покушамо да опишемо неки од објеката, приметићемо да

су неки од њих комплексни те да описивање истих захтева много различитих варијабли,

односно када се све то преведе на језик програмирања, неки објекти захтевају много

атрибута који ће описати њихово стање. Узмимо за пример наш аутомобил. Да би детаљно

описали један ауто, потребно је набројати пуно различитих атрибута попут: боја,

кубикажа, максимална брзина, број врата, марка, модел, годиште, врста горива,

потрошња...

Једноставније би било када бисмо неке од атрибута груписали у једну нову класу

чија би истанца била заправо атрибут наше базне класе. На нашем примеру то би могла

бити класа Мотор чија би инстанца описивала особине сваког објекта класе Аутомобил.

Ево како се то може реализовати у програмском језику JAVA.

14

Ако сада требамо да направимо неки објекат класе Аутомобил који ће се звати нпр.

ауто1, требамо да урадимо следеће:

Уколико се унутар класе као атрибут појави нека друга класа, односно објекат неке

друге класе, веза између те две класе се назива "has a" веза. То је веза која указује да класа

садржи као свој атрибут неку другу класу. Пракса је да уколико класа чија се инстанца

користи као атрибут базне (основне) класе, садржи мали број атрибута и метода се

физички пише у истом фајлу у коме је и базна класа, управо онако као што је то приказано

у претходном примеру.

У програмском језику C#, за такве потребе постоје структуре које се користе када

год је потребно направити "објекат" који не изискује пуно атрибута, односно пуно метода.

Такође се на овом принципу заснива следећи описан концепт.

3.2. Угњеждене класе - Nesting

Уколико је потребно да нека класа има атрибут који ће бити инстанца неке друге

класе, а тад руга класа ће се користити само у ту сврху и нигде више, онда се практикује

принцип да та класа буде угњеждена. Угњеждена класа се назива још и унутрашња класа

тј. inner class, а класа у којој је угњеждена се назива спољашња класа тј. outer class.

Ако би сада ову причу поистоветили са проблемом из природе на примеру класе

Аутомобил имали би још једну класу Мотор, чија би инстанца представљала атрибут

класе Аутомобил. Уколико ће се класа Мотор користити само у класи Аутомобил, онда

можемо применити концепт угњеждених класа (nesting). Угњеждена класа се декларише

унутар домена (scope) спољашње класе. Следи пример написану програмском језику C#

овог концепта на примеру аутомобила.

15

3.3. Веза између класа "is a" . Наслеђивање (Inheritance)

До сада смо користили Аутомобил као пример у разматрању концепата објектно

орјентисаног програмирања. Аутомобил из природе није једини облик моторног возила.

Данас, постоје и камиони, аутобуси, формуле,... Проистиче закључак да класу Аутомобил

можемо сврстати као елемент над скупа Моторно возило. Такође, класа Аутомобил може

представљати над скуп класама као што су: спортски аутомобил, породични аутомобил,...

Следи графичка интерпретација изложеног проблема

16

Можемо речи да сваки Аутомобил "је" (is a) Моторно возило, такође сваки

Породични аутомобил "је" (is a) Аутомобил. Веза is a се у објектно орјентисаном

програмирању назива Наслеђивање (Inheritance). Класа из које је изведена класа која

заузима позицију ниже у хијерархији се назива над-класа или base class. Над-класа се још

назива и класа родитељ (parent), а класа која је наследила над-класу назива се класа дете

(child), односно изведена класа. Процес креирања класе која наслеђује неку класу назива

се извођење класе. Изведене класе наслеђују чланове своје основне (родитељске) класе.

Свака класа која је изведена из неке класе, а касније ће се показати да је свака класа

заправо изведена из једне над-класе, је шира у односу на над-класу у смислу да има нека

додатна поља, неке додатне методе. Из једне класе може се извести не ограничен број

класа, а из сваке изведене класе може се опет извести неограничен број нових класа.

Извођење нове класе из над-класе се и по дубини може вршити неограничен број пута,

што значи да се из сваке изведене класе може поново извести нова класа. Класа родитељ

може имати неограничен број класа деце, баш као што је то случај са природом. Ова веза

се означава 1 : ∞.

Свака класа дете може имати само једну класу родитеља. Ова веза се означава 1 : 1.

У програмском језику C++ постоји концепт вишеструког наслеђивања који се не уклапа у

ова правила, а о коме сада неће бити речи. Што је класа ниже у хијерархијском стаблу, она

има атрибуте који су детаљнији у односу на оне у над-класи. Атрибути у класи која је на

17

врху хијерархијског стабла су најопштији. Узмимо сада за пример класу МоторноВозило

која је над-класа класа Аутомобил, Аутобус и Камион. Она може имати поља модел и

година Производње.

Следи илустрација написана у програмском језику JAVA.

Хоћемо сада да направимо класу Камион која је изведена из класе Моторно

Возило. КласаКамион ће наследити атрибуте и методе које има њена над-класа, а имаће

неке атрибуте и методе који не постоје у над-класи. Ови нови атрибути су мање општи од

оних у над-класи. Кажимо да класа Камион има атрибут имаЛиПриколицу. Истина је да и

над-класа може имати овај атрибут, али то практично није могуће пошто је

МоторноВозило класа која је настала прво, а тек касније класа Камион која је наслеђује.

Тако ће овај атрибут је нелогично да има класа Аутобус.

Ево како се то реализује у JAVA-и.

Кључна реч extends у JAVA-и указује на то да је класа Камион изведена из класе

која се налази иза ове кључне речи, а у овом случају је то класа МоторноВозило. Објекат

класе Камионима ће сва поља и методе које има класа МоторноВозило, али и оне које су

додате у декларацијине саме. У нашем случају објекат класе Камион имаће атрибуте:

модел, годинаПроизводње, имаЛиПриколицу. Ево како би направили објекат класе Камион

који се зове камион1 и који има постављене све своје особине на неке вредности.

18

У природи постоји дилема око тога из чега је настао човек, свет, космос, ... Људи

немају одговор на то питање у природи иако постоје разна веровања и разна убеђења. У

концепту објектно орјентисаног програмирања се зна од чега је настало све, тј. која је

класа родитељска за сваку класу. Класа која је над-класа свим класама је класа Object из

које је све настало. Ова класа се налази на врху хијерархијског стабла. Наша схема класа

са почетка приче о наслеђивању требала би да изгледа овако:

Дакле, над-класа свих класа је класа Object која нема ниједан атрибут, а углавном,

у зависности од програмског језика, поседује следеће методе:

Ево кратког објашњења ових метода

19

- toString ( ) – Метода која се углавном "гази" и која враћа стринг. У класи Object

овај стринг представља референцу на меморијску локацију која је искоришћена за

инстанцирање објекта. Ова метода се углавном редефинише.

- Equals (Object obj) – Враћа вредност true уколико су два објекта једнака на основу

критеријума упоређивања који је дао аутор класе. У супротном враћа вредност

false.

- clone ( ) – прави копију тренутног објекта и враћа референцу истог.

3.4. Преоптерећивање метода – Гажење (Override)

Термин полиморфизам је настао од латинских речи poly што значи много и morph

што значи облик. Дакле под овим термином сматра се да нешто постоји у више

различитих облика (формата).

У концептима објектно орјентисаног програмирања под овим појмом се сматра

могућност да се једна метода која постоји у над-класи може преоптеретити у класи која је

наслеђује. При том прегажена (преоптерећена) метода може радити:

1. све оно што је радила метода у над-класи, па још нешто додатно,

2. нешто ново па онда све оно што је радила у над-класи или

3. само нешто ново

Следи пример написан у програмском језику C#. Замислимо да наша класа

МоторноВозило има методу која се зове Убрзај и која по позиву исписује на екран поруку:

"Убрзање почело".

20

Кључна реч virtual у програмском језику C# зна_и да је овој методи дозвољено да

буде прегажена, док у JAVA-и нпр. свака метода може да се прегази. Напишимо сада у

главној методи програма следеће линије кода:

Дакле инстанциран је објекат класе МоторноВозило који се зове mv и позвана је

метода Убрзај. Резултат ће бити приказан у конзолном прозору и то ће бити текст:

Сада можемо да напишемо класу Аутомобил која је изведена из класе

МоторноВозило и која такође има методу Убрзај, али која је редефинисана. Код у C# би

изгледао овако:

Две тачке (:) иза имена класе означавају да је класа изведена од класе која се налази

иза две тачке (:). Кључна реч override значи да се метода редефинише, односно гази (eng.

override) . Да би се у JAVA-и прегазила нека метода потребно је да само има идентичну

сигнатуру (потпис) као и метода у над-класи. Уколико напишемо сада у главној методи

програма следеће линије кода:

резултат који ће се исписати на екрану конзолног прозора биће:

21

Дакле, инстанцирали смо објекат класе Аутомобил под именом ауто и позвали

методу Убрзај. Пошто метода Убрзај се састоји из две линије кода:

прва казује да се испише текст "Убрзање Аута почело" на конзолни прозор, а друга казује

да се након тога позове метода из над-класе коју смо редефинисали. Уколико би редослед

ове две линије кода био обрнут, онда би се прво позвала прегажена метода из над-класе, а

тек онда бисе извршавао код у текућој класи и излаз из програма би био:

Ако би се пак изоставила линија кода:

онда се прегажена метода извршавала без икаквог кода из над-класе и излаз би онда само

био:

Као што се да приметити у програмском језику C# кључна реч за позивање

прегажене методе из над-класе је base. У програмsком језику JAVA, кључна реч за овакве

потребе је super.

С обзиром да је речено да је конструктор специфична метода којом се дефинише

начин на који се инстанцира објекат властите класе, цела ова прича око преоптерећивања

метода важи, али само са једним изузетком: Немогуће је прво проћи линије кода које су

дефинисане у изведеној класи, па онда позвати конструктор у над-класи. Могуће су само

две варијанте и то:

22

1. позвати конструктор над-класе, па онда написати додатне линије кода које су

специфичне за дете класу или

2. уопште не позивати конструктор из над-класе.

Када је реч о полиморфизму треба споменути једну новину која је такође дошла са

програмерским трендом објектно орјентисаног програмирања, а то је могућност да свака

метода има више различитих потписа у оквиру једне класе, што се може сматрати као

више различитих облика једне методе, односно полиморфизмом.

Примењујући овај концепт мора се држати правила да сваки облик методе:

- мора имати исто име

- мора имати исти тип повратне вредности.

Оно по чему се разликују методе је број, распоред и тип параметара које метода

прима. Дакле сигнатура различитих потписа једне методе се разликује само по основу

параметара које прима, а све остало мора бити идентично. Нпр. метода Console.WriteLine()

у програмском језику C# има 32 различита потписа (облика).

Узмимо на пример методу која треба да израчуна обим кружнице. Нека се она зове

ОбимКруга и нека враћа вредност типа double. Исто тако нека постоје два облика ове

методе и то:

1. она која прима параметре полупречник r и

2. она која прима параметар пречник R.

Пример је дат у програмском језику C#.class

23

Исто тако можемо додати и трећи потпис методе ОбимКруга која ће нпр. примати

полупречник r и вредност броја PI да би смо имали методу која рачуна обим кружнице и

са којом можемо да контролишемо колико је прецизно узета вредност PI. Декларација

методе би изгледала овако:

Број потписа једне методе је неограничен. Исто као и са концептом

преоптерећивања (гажења) све ово важи и за конструкторе, а то је напоменуто у делу када

је објашњаван сам концепт конструктора.

3.5. Запечаћена класа (метода) – Sealed

Уколико из било ког разлога постоји потреба да се нека класа заштити од

могућности да се иста наследи, у програмском језику C# постоји концепт тзв. запечаћених

(sealed) класа. Нажалост, програмски језик JAVA иако је раније настао, не поседује ову

могућност. Уколико сте направили неки комерцијални производ који се састоји од скупа

класа и који желите да заштитите од тога да неки корисник може да исти доради тако што

би неке класе доправио наследивши особине ваших класа, овај концепт је идеално

решење. Иако је напоменуто да JAVA овај механизам не поседује, у JAVA-и се може

24

приступити извесним техникама онемогућавања извожења класа, али концепт као концепт

запечаћених класа не постоји.

Дакле класа из које се не може извести класа је запечаћена, односно sealed класа.

Узмимо за пример класу Аутомобил коју смо направили за комерцијалне сврхе и коју

желимо да онеспособимо да се из ње може извести нека нова класа. Ево како бисмо то

урадили у програмском језику C#:

Кључна реч sealed у програмском језику C# означава да је класа Аутомобил

запечаћена. Ако бисмо сада покушали да направимо класу која ће се звати Нови

Аутомобил и која ће наследити класу Аутомобил биће пријављена грешка јер .Net

Framework зна да се класа Аутомобил не може наслеђивати. Дакле следећи код не може да

се изкомпајлира

Било је речи о полиморфизму, односно о концепту преоптерећивања (гажења)

метода. Намеће се логично питање: да ли је могуће онемогућити кориснику да неку од

метода прегази (override-ује). У програмском језику C# имплементиран је и овај

механизам док JAVA опет нема јасно дефинисане технике за тако нешто, али се и у њој

може извести концепт запечаћивања метода. У C#-у за ово постоје два начина:

1. У потпису методе изоставити кључну реч virtual која казује да се иста метода може

прегазити (override).

2. У потпису метода додати кључну реч sealed којом се забрањује гажење

(преоптерећивање) методе.

25

Биће описана друга техника. Узмимо класу под именом ClassA која има у себи

методу CallMe која је void и коју желимо да заштитимо да се може прегазити уколико се

из класе ClassA изведе нека нова класа. Код би изгледао овако:

Ако би сада декларисали класу која се зове ClassB које је изведена из класе ClassA

код који нам је потребан је следећи.

Унутар класе ClassB не може се прегазити метода CallMe што зна_и да следеће

линије кода приказују грешку.

Корисник значи не може да override-uje методу CallMe. Ако напише следећи код у

главној методи.

Као резултат позива методе CallMe добиће поруку на конзолном прозору:

јер ова метода се у ствари извршава у над-класи, у овом случају у класи ClassA из

које је ClassB изведена.

26

3.6. Апстрактна класа - Abstract

Описан је концепт запечаћених класа где се из неке класе нпр. ClassA не може

извести класа нпр. ClassB. Графичка интерпретација проблема би изгледала овако.

Дакле класа ClassB се не може извести из класе ClassA.

У концепту апстрактних класа над-класа се не може користити. Над-класа се мора

наследити у виду неке дете класе да би се функционалност исте могла искористити. Ако је

над-класа нека класа нпр. ClassA, a класа коју из ње изводимо класа ClassB, графичка

интерпретација би изгледала овако.

Ако узмемо сада класу ПородицниАутомобил која је наслеђена из класе

Аутомобил, а која је пак наслеђена од класе МоторноВозило, шема би изгледала као на

следећој слици.

Речено је да што се класа налази хијерархијски више то има атрибуте који су

општији, а што је класа хијерархијски ниже, атрибути класе су детаљнији. У нашем

27

примеру класа МоторноВозило је највиша у хијерархији и она може имати само атрибуте

који су општи у односу на све класе које ће наследити и ову класу.

Нама, као кориснику, класа МоторноВозило неће служити ничему с обзиром да

има атрибуте који су исувише општи, односно заједнички за сваку класу која се налази

хијерархијски ниже. Опет, обзиром да се из класе МоторноВозило могу извести класе:

Аутобус, Камион, Мотор, Аутомобил,… за које је тешко пронаћи заједничке атрибуте, а

класа МоторноВозило је и у природи нешто што је само по себи опште и не одређено,

класу МоторноВозило можемо прогласити за апстрактну. Следи пример којим ћемо у

програмском језику C# декларисати класу МоторноВозило која је апстрактна.

Кључна реч abstract у програмском језику C#, а и JAVA казује да је класа која је

декларисана апстрактна. Овим смо сада рекли да се објекат класе МоторноВозило не може

инстанцирати, тако да ако у главној методи програма напишемо следећи код:

компајлер ће пријавити грешку јер се апстрактна класа не може инстанцирати.

Оно што можемо је да декларишемо класу под именом Аутомобил која наслеђује

класу МоторноВозило да би искористили функционалност класе МоторноВозило. Ево

како би изгледао код у C#.

Ако би сада покусали да инстанцирамо објекат класе Аутомобил:

28

Компајлер не би пријавио никакву грешку јер сада класа Аутомобил није

апстрактна. Сада можемо користити сву функционалност над-класе јер можемо

инстанцирати објекат класе Аутомобил.

При коришћењу принципа апстракције класа треба имати у виду следеће:

- апстрактна класа се не може инстанцирати,

- конструктор класе не може бити апстрактан,

- из апстрактне класе се може извести класа која може, а не мора бити апстрактна.

Аналогно принципу запечаћених класа и запечаћених метода, постоји и концепт

апстрактних класа и апстрактних метода. Апстрактна метода је она која се мора прегазити

(override-овати) да би се користила. Ова метода не сме имати тело (body) методе.

Апстрактна метода се може декларисати једино у апстрактној класи.

Следи пример написан у програмском језику C# у коме је декларисана апстрактна

класа ClassA која поседује методу CallMe која је апстрактна и класа ClassB која наслеђује

класу ClassA и која има редефинисану методу CallMe.

Кључна реч abstract у програмском језику C#, а и JAVA, казује да је метода која је

декларисана апстрактна. У класи која је изведена из апстрактне над-класе, да би се

користила метода која је означена за апстрактну се мора прегазити (override-овати).

29

Дакле, при коришћењу принципа апстракције метода треба имати у виду следеће:

1. апстрактна метода може се декларисати једино у апстрактној класи,

2. апстрактна метода не сме имати тело методе (body) и

3. да би се користила апстрактна метода, она се мора прегазити (override-овати) у

изведеној класи.

3.7. Интерфејси (interfaces)

Оно што има програмски језик C++, а што га чини конфузним је могућност

вишеструког наслеђивања. Дакле једна класа може наследити особине више, а не само

једне класе. Са програмским језицима JAVA и C# могућност вишеструког наслеђивања је

укинута из чега следи да једна класа може имати само једну родитељску класу. Да би

схватили шта се мисли под то када се каже да концепт вишеструког наслеђивања може

бити конфузан, погледајмо следећи пример.

Узмимо нпр. класу Аждаја и класу Риба. Желимо да направимо неку класу

СуперБиће која ће наследити особине обе ове класе. Аждаја може да бљује ватру, а Риба

не, значи овај атрибут узимамо од Аждаје.

Риба може да дише под водом, а Аждаје не, значи ову особину ћемо узети од рибе.

И Аждаја и Риба имају очи које су сличне, па ћемо особину око узети од било које класе.

Али шта ћемо са особином крљушт? Коју ћемо узети? Концепт вишеструког наслеђивања

је у оваквој ситуацији немоћан. Дакле, концепт вишеструког наслеђивања нам не може

дати одговор на ово питање, али концепт интерфејса (interface) може.

Следе неке од дефиниција интерфејса (interface):

- Протокол понашања који може да имплементира било која класа у хијерархији.

- Именована колекција метода без имплементације (и евентуално неких константи).

Дакле, интерфејс представља "уговор" који потписује свака класа која га

имплементира. Сам интерфејс се састоји од низа потписа метода које немају тело (body).

Шта значи да када нека класа имплементира интерфејс "потписује уговор о коришћењу"?

30

То значи да свака класа која имплементира неки интерфејс мора имплементирати све

методе које има декларисан интерфејс, без обзира да ли ће користити све методе или не.

Интерфејс може, а не мора, поред сигнатура метода садржати и декларисане неке

константе. Једна класа може наследити само једну класу док та иста класа може

имплементирати неограничен број интерфејса. Оно што је једино важно је то да та класа

мора имплементирати све методе свих имплементираних интерфејса. Такође, интерфејс

може наследити неки интерфејс из чега следи да су и интерфејси хијерархијски уређени с

тим што је ово хијерархијско стабло независно од хијерархијског стабла класа.

Следи пример реализације концепта интерфејса у програмском језику JAVA.

Креирајмо интерфејс који се зове InterfacePovršina и који има сигнатуру методе

израчунај површину.

Кључна реч interface указује на то да је у питању интерфејс, а не класа. Ово је

битно јер се екстензије фајлова и класа и интерфејса не разликују. У програмском језику

JAVA то је екстензија *.java, односно *.class, а у програмском језику C# то је *.cs.

Направимо сада класу Квадрат која имплементира наш интерфејс.

31

Иза имена класе налази се кључна реч implements која указује на то да наша класа

имплементира наведени интерфејс. Иза ове кључне речи се могу набројати сви интерфејси

које имплементира нека класа тако што се наводе имена истих и раздвајају запетом (,).

Имплементацијом интерфејса InterfacePovršina ми смо "потписали уговор" да ћемо

имплементирати све методе које има интерфејс и дефинисати их. Интерфејс

InterfacePovršina има само једну методу израчунајПовршину коју смо редефинисали да

врача производ дужина страница квадрата.

Хајде сада да направимо класу Правоугаоник која такође имплементира интерфејс

InterfacePovršina.

С обзиром на то да је и ова класа имплементирала наш интерфејс и она море

имплементирати и дефинисати методу израчунајПовршину што је и урађено са том

разликом да корисник сада добија производ две различите странице правоугаоника што је

заправо површина истог.

Сада можемо да направимо демо класу у којој ћемо показати како се интерфејс

заправо користи. Ево комплетног кода класе DemoClass.

32

У main методи ми правимо инстанцу ip која је заправо инстанца интерфејса

InterfacePovrsina, а не неке класе. Ако хоћемо методу израчунајПовршину да користимо

онако како је дефинисану класи Квадрат ми кажемо:

Чиме смо рекли да интерфејс ради са класом Квадрат, односно да се класа

Квадрат пријављује интерфејсу InterfacePovrsina. Број 4 је прослеђен конструктору класе

Квардат. Ако сада желимо да позовемо методу израчунајПовршину ми кажемо инстанци

интерфејса InterfacePovrsina да позове ову методу али из оне класе која се пријавила, а то

је у ово случају класа Квадрат. Па позовимо методу.

Вредност променљиве x биће 4 • 4 што је 16.

Сада можемо пријавити класу Првоугаоник која је такође имплементирала наш

интерфејс.

Бројеви 2 и 4 су прослеђени као параметри конструктору класе Правоугаоник. Када

бисмо сада позвали методу израчунајПовршину кодом:

33

вредност променљиве x била би повратна вредност методе израчунајПовршину, али

класе Правоугаоник јер је она последња пријављена инстанци интерфејса InterfacePovrsina

(ip), а то би било 2 • 4 што је 8.

4. ОБЈЕКТНО ОРЈЕНТИСАНО ПРОГРАМИРАЊЕ ПОД WINDOWS

ОПЕРАТИВНИМ СИСТЕМОМ

4.1. Појам кросплатформност (Cross-platform)

Кросплатформност је термин који је познат и под називом интероператибилност, а

који означава могућност да једна апликација може радити на више различитих

оперативних система. Намеће се питање да ли је могуће креирати апликацију која ће моћи

радити на различитим оперативним системима и ако је могуће онда како.

Размишљајући о проблему интероператибилности треба имати на уму чињенице

да:

- сваки оперативни систем има јединствен кернел,

- сваки оперативни систем има другачији FileSystem (У Windows-u су то FAT,

FAT32, NTFS, WFFS),

- сваки оперативни систем другачије реализује и распоређује приоритет нити

- сваки оперативни систем другачије користи оперативну меморију,

- …

Посматрајући ове чињенице, надзире се закључак да нешто тако не постоји. Ако би

постојало,онда би тај направљен програм био изузетно великих димензија и у себи би

садржао описе како се понаша у ком оперативном систему. Са друге стране, да ли је

могуће обухватити све оперативне системе? Свакако није јер је немогуће и пребројати све

оперативне системе. Значи идеална интероператибилност (кросплатформност) не постоји.

Решење које је споменуто за остварење кросплатформности је могуће остварити

само у случају да одређена апликација садржи описе понашања за одређен број

оперативних система. Такви пројекти постоје. Један од њих је RealBasic

34

(http://www.realbasic.com) чије се компајлиране апликације могу извршавати на следећим

оперативним системима:

- Windows 98, SE, Me, Nt4, 2000, XP

- Linux x86

- Mac OS X

Међутим постоји много боље решење реализације програмске кросплатформности

које је одавно уочила компанија SUN Microsystems која је аутор програмског језика JAVA.

4.2. Реализација кросплатформности са програмским језиком Java

Слоган JAVA-е када се појавила је био: "Made to work anywhere." – Направљено да

ради свуда.

Програмски језик JAVA можемо рећи да је зачетник приче идеје реализације

кросплатформности апликација. Наиме, аутори програмског језика JAVA су се хвалили

речима: "Дајте нам било коју процесорску машину која има било какав оперативни систем

и JAVA апликација ће се моћи покренути са ње". Да ли су људи из Sun-а успели да

преброје све оперативне системе? Не, нису. Њихово решење лежи у следећем:

Компанија која је аутор овог програмског језика с обзиром да је велика, моћна и да

има велику количину ресурса, ангажује велики број стручњака који програмирају по једну

апликацију за конкретан оперативни систем која пак омогућава реализацију JAVA

апликације на било којој платформи. Та апликација се зове Јава Виртуелна Машина (Java

Virtual Machine) скраћено JAVA VM. Аутори JAVA-е поред развоја самог програмског

језика стално праве нове верзије Јава Виртуелне Машине за најразличитије оперативне

системе.

У истини за вољу онај слоган "Made to work anywhere" се мора модификовати у

смислу да JAVA апликације раде свуда, али где има Јава Виртуелне Машине. Данас

постоји много верзија Јава Виртуалне Машине, почев од оних за различите рачунарске

оперативне системе као што су: Windows, Linux, Mac OS, UNIX,..., па до верзија које су

имплементиране за различите оперативне системе уређаја попут: ПДА, Мобилних

35

телефона итд. Јава програмери не морају бринути о кросплатформности јер њихове

апликације ће радити на било ком оперативном систему који има JAVA VM.

Ово решење не захтева велику величину извршног фајла јер се сама апликација

везује не за специфичности које има оперативни систем већ за специфичности које има

програмски језик, а JAVA VM је та која се везује за сам оперативни систем и његове

специфичности.

4.3. Реализација кросплатформности са програмским језиком C#

Компанија Microsoft је видела велику конкуренцију у програмском језику JAVA и

дуго година се против ње борила покушајима да освоји свет својим оперативним системом

Windows у коме су једино могли радити програмски језици из Microsoft-овог пакета Visual

Studio: Visual Basic, FoxPro i C++.

Схвативши да полако губи трку Microsoft је морао да предузме нешто и почетком

2002. Године објављује свој нови производ под називом Microsoft Visual Studio .Net. Овај

производ је донео неке радикалне потезе као на пример то да се програмски језик FoxPro

више не производи. Microsoft је пре свега направио програмски језик који у многоме

подсећа на програмски језик JAVA, који је једноставан као Visual Basic и моћан као C++ и

који садржи све што има и JAVA, али са још неким корисним додацима. Дакле, ради се о

програмском језику C#.

Такође, појавом овог новог алата дошло је и до новог концепта коме је приступио

Microsoft издавши свој нови алат, а то је концепт кросплатформности с тим што је Visual

Studio .Net отишао корак даље. Наиме, оно што је за JAVA-у Java Virtualna Mašina, to je za

Visual Studio .NetFramework. Тако да сада апликације које се пишу на Microsoft-овим

развојним језицима такође могу радити на различитим оперативним системима, али под

условом да тај оперативни систем поседује .Net Framework. За сада Microsoft је написао

.Net Framework само за оперативне системе за које је он аутор, а то су оперативни системи

за рачунаре и оперативни системи за Pocket PC уређаје и мобилне телефоне.

36

На шта се мисли када се каже да је Microsoft отишао корак даље у реализацији

кросплатформности. Сваки програмски језик из пакета Visual Studio .Net се преводи у

Intermediate Language (IL) односно у Microsoft Intermediate Language (MIL). Овим је

постигнуто је то да се сада сваки програмски језик било да је из Microsoft-а или не може

превести у MIL и извршавати се уз помоћ .Net Framework-а. Компанија Borland је одавно

направила подршку да се Delphi апликације компајлирају у MIL.

Да би се неки програмски језик превео у MIL, потребно је да испуњава неке од

захтева .NetFramework-а који су дефинисани у Common Language Specification - CLS.

Дакле CLS представља спецификацију минималних захтева које сваки .NET језик мора да

подржи у циљу постизања интеграције језика.

4.4. Специфичности објектно орјентисаног програмирања везане за оперативни

систем Windows

Windows апликације које су направљене у неким од језика који нису

кросплатформни су скупови бинарних информација које оперативни систем као

интерпретер реализује. Зато је и било немогуће направити 100% кросплатформни програм

јер сваки оперативни систем различито интерпретира скуп бинарних кодова. У Windows

оперативном систему, апликацију (програм) односно софтвер пре свега чини фајл са

екстензијом *.exe (Executable file), док на пример у оперативном систему Linux не постоји

извршни, односно exe фајл. Ово би се могло сматрати специфичношћу не само

оперативног система Windows већ и сваког другог. Како је онда JAVA једино могла да

имплементира концепт кросплатформности? Одговор се сам намеће. Идеја коју су људи из

SUN-a осмислили је једино могућа ако је апликација која се извршава текстуалног облика,

а не бинарног. Зато интерпретацију JAVA апликације на реализује оперативни систем, већ

постоји нешто између, а то је Јава Виртуална Машина која преводи сад тај текстуални код

у бинарни који ће извршити систем. Наравно JAVA VM је написана у бинарном облику

који разуме оперативни систем на коме се извршава.

Следи графичка интерпретација извршавања 32bit-не Windows EXE апликације.

37

Значи exe фајл, који је бинарног облика интерпретира Windows као оперативни

систем и резултат се приказује финалном кориснику. Овакве апликације се извршавају

најбрже, али имају ману да се могу извршити само ако их оперативни систем Windows

извршава.

Ево како се извршава JAVA апликација на Windows оперативном систему.

Решење које користи JAVA има један корак више од претходног, а то је JAVA VM

која посредује између Windows-а као оперативног система и JAVA апликације. Ово

решење је спорије, али на месту на коме се налази Windows као оперативни систем може

стојати било који други оперативни систем под условом да за тај оперативни систем

постоји JAVA VM.

Може се поставити питање да ли је JAVA апликација коју интерпретира JAVA VM у

ствари изворни код (source code) апликације коју је програмер написао. Одговор је

негативан. Изворни код који програмер напише у програмском језику JAVA се компајлира

(Compile) у тзв. JAVA бинарни код (JAVA Byte Code) који је заправо JAVA апликација коју

интерпретира JAVA Виртуална Машина. Ово је урађено из два очигледна разлога:

1. Заштита изворног кода, JAVA Byte Code је бинарни код који разуме једино JAVA

VM, а који је нечитљив људима.

38

2. Када се компајлира JAVA изворни код, проверавају се све синтаксне грешке и

тек ако је све у реду онда се прави JAVA Byte Code. JAVA апликација не може

имати синтаксне грешке, нема ни један коментар, нити иједан размак (blank

space) те је JAVA Byte Code много мање величине него ли изворни, што

обезбеђује брже извршавање.

Констатација да је JAVA апликација текстуални фајл заправо није тачна у

техничком погледу, напротив, она је бинарна, али са аспекта ко извршава ту апликацију

она јесте текстуална, јер за оперативни систем без JAVA VM, JAVA апликација (JAVA Byte

Code) је само текст. Ево како изгледа процес креирања JAVA апликације.

Фајл који представља JAVA изворни код има екстензију *.java. Када се компајлира

овај фајл добија се фајл са екстензијом *.class који је заправо JAVA Byte Code који сада

JAVA VM интерпретирају бинарне вредности специфичне за оперативни систем на коме

се извршава.

Да би направили јава апликацију у Windows оперативном систему требамо изворни

код снимити са екстензијом *.java. Затим позивамо апликацију под именом javac.exe што

је заправо компајлери као аргумент прослеђујемо путању фајла који смо снимили.

Уколико је све у реду, добићемо изгенерисан фајл који има исто име као и изворни фајл

али има екстензију *.class. Да би сада интерпретирали нашу апликацију, потребно је да

позовемо програм под именом java.exe (интерпретер) и као аргумент проследимо class

фајл који смо претходно искомпајлирали.

39

5. ЗАКЉУЧАК

Трка између два најозбиљнија конкурента Sun Microsystems и Microsoft-a творца

JAVA-e и .Net језика донела је са собом многе нове, добре производе који пак са собом

носе повољности које програмер може да користи. Објектно орјентисано програмирање

као концепције тренутно актуелан и скоро сви програмски језици се полако окрећу њему.

Узимање објектно орјентисаног програмирања као стандарда ова два софтверска

гиганта су у виду својих програмских језика промовисала и са могућношћу

интероператибилности, односно извршавања апликација писаним у овим језицима на

условно свим оперативним системима. Ово нас доводи до закључка да објектно

орјентисано програмирање, односно језици који су се у потпуности окренули овом

концепту руше специфичности које има сваки оперативни систем, а програмеру

омогућавају да не размишља о томе како омогућити својој апликацији да ради на неком

оперативном систему већ да се у потпуности посвети само квалитету своје апликације.

Онај ко брине о кросплатформности је произвођач програмског језика. Дакле, тежи се ка

томе да програмер данас треба једино да овлада концептима објектно орјентисаног

програмирања, а његова "објектно орјентисана апликација" ће радити на Windows

оперативном систему и на било ком другом.