back_rest
ex mod coder
- Член од
- 19 јули 2006
- Мислења
- 1.590
- Поени од реакции
- 107
Ова ми гние подолго време на компјутер, па ајде да го ставам овде. Можда некој ќе му се види интересно. Ако се разбирате во програмирање (Java или C++) комотно читајте надолу.
night_club.cpp (појаснување на структурата и начин на функционирање)
- Главна погонска класа: cClub
Оваа класа е самиот зачеток на некое дело кое би требало да го користи овој source code. Самата класа претставува container и data consumer, односно истата е дизајнирана да во себе содржи објекти инстанцирани од соодветни компатибилни класи. За да нејзината работа биде функционална, просперитетна и пред се профитабилна мора од истата класа да се инстанцира објект (во понатамошниот текст само oClub) кој што ќе биде алоциран на релативно поголема меморија и притоа многу пожелно е да се наоѓа во централното RAM подрачје. Самиот овој објект без ништо додадено се класифицира како „дупка“.
- #region frame
За збогатување на корисничниот интерфејс и примамливоста на овој објект, а притоа и за оспособување на некоја негова логична работа, потребно е кон него да се придружат објекти инстанцирани од класите во #region frame и тоа: полиња од објекти инстанцирани од класите cShank, cMasa и cStol; матрица од објекти инстанцирани од полиморфно наследените класи од основната класа cPijalok и една единствена инстанца од мултимедијалната класа cDJSet. Количината на изведените објекти од првите три класи зависи од меморијата алоцирана од oClub а големината на матрицата е на база на претпоставка колку вкупно податоци ќе се пренесат од oClub до различните end-users во рок од една сесија. Според тоа, класата cPijalok се однесува како data-container односно како средство за пренос на податоци од oClub до некој евентуален end-user. Во организацијата на cClub, од класите cDJSet, cShank, cMasa и cStol се инстанцираат објекти во private секцијата a објектите од cPijalok се protected.
Комерцијалните верзии на овој source code содржат и редица класи полиморфно наследени од класата cDiskoSvetla чии што задачи се да го збогатат интерфејсот и да привлечат повеќе нови корисници.
- #region bots
Овде како основна класа е cLicnost. Од оваа класа понатаму се изведуваат cVraboten и cGostin.
Од класата cVraboten се наследуваат класите cKonobar, cShanker, cDJ, cSecurity и cTancher/cTancherka. Овие класи се пријавени како friend на основната класа cClub што значи дека имаат директен пристап до private и protected секцијата на истата. Причината што овие објекти се инстанцираат е тоа што тие служат како pipe-line за пренос на податоци помеѓу oClub и евентуалните end users.
- #sub_region user_bots
Класата cGostin е основната класа од која се инстанцираат објектите корисници, односно end-users. Од оваа класа, се изведуваат класите cGMasko и cGZensko од кои потоа полиморфно се наследуваат: cFraer, cSeljak, cDenser, cBogatash, cEminenten; cMirna, cRaspushtena, cShmizla, cEmancipirana, cRomanticna, cFrigidna и ред други...Секоја од овие класи има по некоја особина во својата private секција (дали податок или метод) со која се разликува од останатите.
Класата cGostin а со тоа и сите класи наследени од неа имаат глобално два начина на примање на податоци од класата cClub и тоа: виртуелно фреквенциски и виртуелно течно.
Принцип на функционирање
Објектите инстанцирани од класите cDJSet и cDJ се покренувачи на целиот процес за АРП. Имено, тие праќаат фреквенциски податоци кои преку околните мемориски ќелии допираат до самите end-user објекти кои се наоѓаат во а понекогаш ако фреквенциите се многу добро одберени и вон алоцираната меморија од oClub. Овие фреквенции, кај различните end-user-и предизвикуваат различни ефекти. Ниските и високите тонови се добредојдени и полесно прифатени кај поеминентните класи, а додека средните тонови се по дефиниција почесто прифаќани од недоволно информираните и долго време локални класи. Самите овие податоци во некој смисол се encode-ирани бидејќи наложуваат потреба од примање податок на другиот рецептор со цел ефектот да биде комплетен, и информацијата да пристигне целосно кај самиот корисник.
Овде пак се задолжени објектите инстанцирани од класите cKonobar, cShanker и главниот container на матрицата од cPijalok – cShank. Имено pipe-line-от што се остварува тука е cShank->cShanker->cKonobar->&cGostin. Понекогаш се користи и скратената варијанта cShank->cShanker->&cGostin, но притоа bit-rate-от е мнооооогу помал и самите рутери остануваат без работа и поради тоа можно е да настанат административни конфликти.
Овде битно е и да се наведе дека поголемот број на објекти од cPijalok содржат податоци кои во одредена мера го нарушуваат правилното работење на самиот end-user објект. Но што е најпарадоксално, тоа е всушност и многу барано од страна на истиот.
Изведената класа cSecurity е задолжена за справување со непожелните exceptions во процесот на размена на податоци во oClub. Имено, ако некој објект инстанциран од класите наследени од cGostin направи некој exception, објект инстанциран од cSecurity веднаш му прави throw од oClub и притоа наместо catch му прави ban на тој објект односно го брише од базата на податоци на oClub за неодредено време.
Класите cTancher и cTancherka се задолжени за справување со idle-периодот на секоја класа изведена од cLicnost. Ако било кој објект, инстанциран од класа наследена од претходната се најде во фаза да не врши размена на податоци со ниеден инстанциран објект од наведените погоре, тогаш неговата метода watch е повикана од страна на објектите инстанцирани од cTancher и cTancherka со потребните аргументи (дали default или optional не е битно) за да во никој момент кај него не се предизвика незаинтересираност или отфрленост односно виртуелното чувство дека никој не сака да прави размена на податоци со него.
Е сега како за на крај, што е поентата на сево она горе. Имено ако, во сиот објектно-ориентиран хаос досега се сретнат два објекти чија што размена на податоци е многу глатка и им се погаѓаат сите методи со потребниот број на аргументи, тогаш размената преминува на нареден advanced степен. Во тој случај, најчесто овие два објекти (во глобала се инстанцирани од наследени класи од cGostin и со обратни приватни вредности на pol односно едната наследена од cGMashko а другата од cGZensko) го напуштаат oClub и одат некаде во надворешниот сајбер простор. Таму тие преминуваат на ultimate размена на податоци што во крајна граница значи и размена на милиони објекти од класата cGenetskiMaterijal. Сепак ова е доста деликатен процес поради тоа што ако не се користат некои заштитни протоколи како dureX 1.2 или sportexX 2.3 можно е после 9 месечно процесирање на податоци да се инстанцира нов објект кој ќе ги наследи особините на двата претходни објекти. Но, со конкретно ракување со истиот процес се доаѓа до стадиум на максимално виртуелно задоволство на двата објекти што во иднина би значело комплетно кохабитирање меѓу истите и создавање на повеќе child-објекти наведени како претходно.
night_club.cpp (појаснување на структурата и начин на функционирање)
- Главна погонска класа: cClub
Оваа класа е самиот зачеток на некое дело кое би требало да го користи овој source code. Самата класа претставува container и data consumer, односно истата е дизајнирана да во себе содржи објекти инстанцирани од соодветни компатибилни класи. За да нејзината работа биде функционална, просперитетна и пред се профитабилна мора од истата класа да се инстанцира објект (во понатамошниот текст само oClub) кој што ќе биде алоциран на релативно поголема меморија и притоа многу пожелно е да се наоѓа во централното RAM подрачје. Самиот овој објект без ништо додадено се класифицира како „дупка“.
- #region frame
За збогатување на корисничниот интерфејс и примамливоста на овој објект, а притоа и за оспособување на некоја негова логична работа, потребно е кон него да се придружат објекти инстанцирани од класите во #region frame и тоа: полиња од објекти инстанцирани од класите cShank, cMasa и cStol; матрица од објекти инстанцирани од полиморфно наследените класи од основната класа cPijalok и една единствена инстанца од мултимедијалната класа cDJSet. Количината на изведените објекти од првите три класи зависи од меморијата алоцирана од oClub а големината на матрицата е на база на претпоставка колку вкупно податоци ќе се пренесат од oClub до различните end-users во рок од една сесија. Според тоа, класата cPijalok се однесува како data-container односно како средство за пренос на податоци од oClub до некој евентуален end-user. Во организацијата на cClub, од класите cDJSet, cShank, cMasa и cStol се инстанцираат објекти во private секцијата a објектите од cPijalok се protected.
Комерцијалните верзии на овој source code содржат и редица класи полиморфно наследени од класата cDiskoSvetla чии што задачи се да го збогатат интерфејсот и да привлечат повеќе нови корисници.
- #region bots
Овде како основна класа е cLicnost. Од оваа класа понатаму се изведуваат cVraboten и cGostin.
Од класата cVraboten се наследуваат класите cKonobar, cShanker, cDJ, cSecurity и cTancher/cTancherka. Овие класи се пријавени како friend на основната класа cClub што значи дека имаат директен пристап до private и protected секцијата на истата. Причината што овие објекти се инстанцираат е тоа што тие служат како pipe-line за пренос на податоци помеѓу oClub и евентуалните end users.
- #sub_region user_bots
Класата cGostin е основната класа од која се инстанцираат објектите корисници, односно end-users. Од оваа класа, се изведуваат класите cGMasko и cGZensko од кои потоа полиморфно се наследуваат: cFraer, cSeljak, cDenser, cBogatash, cEminenten; cMirna, cRaspushtena, cShmizla, cEmancipirana, cRomanticna, cFrigidna и ред други...Секоја од овие класи има по некоја особина во својата private секција (дали податок или метод) со која се разликува од останатите.
Класата cGostin а со тоа и сите класи наследени од неа имаат глобално два начина на примање на податоци од класата cClub и тоа: виртуелно фреквенциски и виртуелно течно.
Принцип на функционирање
Објектите инстанцирани од класите cDJSet и cDJ се покренувачи на целиот процес за АРП. Имено, тие праќаат фреквенциски податоци кои преку околните мемориски ќелии допираат до самите end-user објекти кои се наоѓаат во а понекогаш ако фреквенциите се многу добро одберени и вон алоцираната меморија од oClub. Овие фреквенции, кај различните end-user-и предизвикуваат различни ефекти. Ниските и високите тонови се добредојдени и полесно прифатени кај поеминентните класи, а додека средните тонови се по дефиниција почесто прифаќани од недоволно информираните и долго време локални класи. Самите овие податоци во некој смисол се encode-ирани бидејќи наложуваат потреба од примање податок на другиот рецептор со цел ефектот да биде комплетен, и информацијата да пристигне целосно кај самиот корисник.
Овде пак се задолжени објектите инстанцирани од класите cKonobar, cShanker и главниот container на матрицата од cPijalok – cShank. Имено pipe-line-от што се остварува тука е cShank->cShanker->cKonobar->&cGostin. Понекогаш се користи и скратената варијанта cShank->cShanker->&cGostin, но притоа bit-rate-от е мнооооогу помал и самите рутери остануваат без работа и поради тоа можно е да настанат административни конфликти.
Овде битно е и да се наведе дека поголемот број на објекти од cPijalok содржат податоци кои во одредена мера го нарушуваат правилното работење на самиот end-user објект. Но што е најпарадоксално, тоа е всушност и многу барано од страна на истиот.
Изведената класа cSecurity е задолжена за справување со непожелните exceptions во процесот на размена на податоци во oClub. Имено, ако некој објект инстанциран од класите наследени од cGostin направи некој exception, објект инстанциран од cSecurity веднаш му прави throw од oClub и притоа наместо catch му прави ban на тој објект односно го брише од базата на податоци на oClub за неодредено време.
Класите cTancher и cTancherka се задолжени за справување со idle-периодот на секоја класа изведена од cLicnost. Ако било кој објект, инстанциран од класа наследена од претходната се најде во фаза да не врши размена на податоци со ниеден инстанциран објект од наведените погоре, тогаш неговата метода watch е повикана од страна на објектите инстанцирани од cTancher и cTancherka со потребните аргументи (дали default или optional не е битно) за да во никој момент кај него не се предизвика незаинтересираност или отфрленост односно виртуелното чувство дека никој не сака да прави размена на податоци со него.
Е сега како за на крај, што е поентата на сево она горе. Имено ако, во сиот објектно-ориентиран хаос досега се сретнат два објекти чија што размена на податоци е многу глатка и им се погаѓаат сите методи со потребниот број на аргументи, тогаш размената преминува на нареден advanced степен. Во тој случај, најчесто овие два објекти (во глобала се инстанцирани од наследени класи од cGostin и со обратни приватни вредности на pol односно едната наследена од cGMashko а другата од cGZensko) го напуштаат oClub и одат некаде во надворешниот сајбер простор. Таму тие преминуваат на ultimate размена на податоци што во крајна граница значи и размена на милиони објекти од класата cGenetskiMaterijal. Сепак ова е доста деликатен процес поради тоа што ако не се користат некои заштитни протоколи како dureX 1.2 или sportexX 2.3 можно е после 9 месечно процесирање на податоци да се инстанцира нов објект кој ќе ги наследи особините на двата претходни објекти. Но, со конкретно ракување со истиот процес се доаѓа до стадиум на максимално виртуелно задоволство на двата објекти што во иднина би значело комплетно кохабитирање меѓу истите и создавање на повеќе child-објекти наведени како претходно.