என் காதலி

10 நாளா பாருங்க இந்த பொண்ணு நின்னா, நடந்தா, ஒரு லுக் விட்டா, சும்மா பேரு சொன்னாலே போதும் தூக்கம் போச்சி :-). என்னோட இதயத்தை ஹோல்சேல்ல வாங்கிடாங்க(கவனிக்க மரியாதை). என்னோட பொது வாழ்கைல இது மாதிரி ஆனது இல்லை. இதுல என்ன விஷேசம்ன்னா இவங்க என்னோட முதல் காதலி கூட அமைச்ச கூட்டணி இருக்கே. இத எல்லாம் ப்லொக்ல ஒரு பதிவுல எழுத முடியாது. இருந்தாலும் ஒரு முயர்ச்சிதான். [எப்படி இவங்கள இந்தன நாளா மிஸ் பண்ணுனேன்னு நினைச்சா எனக்கே அவமானமா இருக்கு.]


என்னடா ஆச்சி இவனுக்கு வரு.வா.சங், பாட்டு, அறிக்கை இப்படி நல்லாத்தானே இருந்தான்னு நீங்க கேக்குறது எனக்கு புரியுது. இந்தாலும் 10 நாளா இது வேர Additional Responsibility யா வந்துடுச்சி. இதுல வீடு வேர போன வாரம் மாத்திடேன் கடைக்கு பக்கத்திலயே. Recent Past ல என்னய இப்படி யாரும் மண்டை காயவைக்கல. இவங்கதான் இப்ப லிஸ்ட்ல Number 1 இருக்குறாங்க. அதுனாலதான் இவங்களை பத்தி உங்க கிட்ட சொல்லாம்ன்னு.

பில்டப்பு போதும்ன்னு நினைக்குறேன்.

இவங்க பேரு AOP (Aspect Orieneted Programming) . இவங்களை காதலிக்க செய்ய வேண்டியது AOSD (Aspect Oriented Software Development). Real simple Task Buddy :-)


என்னதான் OOPS அழகி அம்சமா இருந்தாலும், சில குறைகள் இருக்கு. நம்ம பாஷைல இதுக்கு 'Cross Cutting Concerns' நு சொல்லாம். இதுகளை அள்ளவும் முடியாது, தள்ளவும் முடியாது.

ஆனா எங்க ஆளு இதை ஈஸியா சால்வ் பண்ணுவாங்க.

கிராஸ் கட்டிங் கன்சர்ன்ஸ் உதாரணம்.

இப்ப ஒரு பேங்க்ல ஒரு ட்ரான்ஸாக்சன்னுக்கு code எழுதுனா அதுல கண்டிப்பா பிஸினஸ் லாஜிக்தான் core.

இந்த code தான் பிஸினஸ் லாஜிக்


void transfer(Account fromAccount, Account toAccount, int amount) {
if (fromAccount.getBalance() < amount) {
throw new InsufficientFundsException();
}

fromAccount.withdraw(amount);
toAccount.deposit(amount);
}


இப்படி Code எழுதுனா Hackers எல்லாம் ஒரே நாள்ல பேங்க கொட்டடிச்சிருவாங்க. இது போக டேட்டா லாஸ் இல்லாம இருக்க DB வேணும். என்ன நடந்ததுன்னு தெரிய Logging வேணும். இது மாதிரி இண்ணும் நிறைய வேணும். அதுனால ரியல் வேல்ட்க்கு பக்கத்துல போற மாதிரி Codeட மாத்தணும்னா atleast இப்படியாவது இருக்கணும்.


void transfer(Account fromAccount, Account toAccount, int amount) {
if (!getCurrentUser().canPerform(OP_TRANSFER)) {
throw new SecurityException();
}

if (amount < 0) {
throw new NegativeTransferException();
}
if (fromAccount.getBalance() < amount) {
throw new InsufficientFundsException();
}

Transaction tx = database.newTransaction();

try {
fromAccount.withdraw(amount);
toAcount.deposit(amount);
tx.commit();
systemLog.logOperation(OP_TRANSFER, fromAccount, toAccount, amount);
}
catch(Exception e) {
tx.rollback();
}
}


இப்ப Transaction, Security, Logging, etc எல்லாம் Cross Cutting Concerns நு தெரியும். இது போக திடும்ன்னு செக்யுரிட்டிக்காக புது வழிய கொண்டுவந்தா, இருக்குற Code புரிஞ்சி அத மாத்துறதுக்குள்ள...

எங்க ஆளு AOP உதவியால இப்படி Cross Cutting Concerns எல்லாத்தையும் தனியா Aspects சா பிரிச்சி எழுத முடியும்.

வழக்கமாக Aspect Programming ல Advice & Joint Points எல்லாம் இருக்கும்.

ஒரு Aspect எப்படி Base Program கூட பேசுதுன்னு முடிவெடுக்குறது Joint Point Model(JPM).

இந்த JPM

1) Aspects ச எப்படி உபயோகப்படுத்துவது.

2) Point Cuts (group of related Joint Points )ல இருந்து எப்படி சரியான Joint Points ச எடுக்குறது. அதாவது எப்படி Regular Expression ச சரியா உபயோகப்படுத்துவது. (Regular Expressions - UNIX ல இருந்த Pattern Matching Technique கிட்ட இருந்து ஆட்டய போட்டதுன்னு நான் நினைக்குறேன்)

3) சரியா எப்படி Advice ச உபயோகப்படுத்துவது. முடிவு செய்யணும்


AspectJ ச 2 மாதிரியா JPM உபயோகப்படுத்தலாம்.


A) PointCuts & Advice (Dynamic JPM)

I) PointCut Code கிட்டத்தட்ட இப்படி இருக்கும்

pointcut set() : execution(* *.set*( Amount Deposit, Amount Withdraw) ) && this(Point);

இதுல RunTime ல method execution, Object Instantiation, Exception Throwing இருக்கும். அதுனால Generally Heavy Mutational Objects எல்லாம் சரியா இருக்காதுன்னு நினைக்குறேன்.

II) Advice Code கிட்டத்தட்ட இப்படி இருக்கும்

after() : set() { Display.update(); }

இந்த Advice, PointCut true வா இருந்தா மட்டும்தான் execute ஆகும். தனியான function மாதிரி கூப்பிட முடியாது

B) InterType Declarations

Code

aspect VisitAspect {
Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}



இதுல நம்மளோட புது Declarations கூட சேத்துக்கலாம்.

சரிப்பு எதோ ஒரு மூளைக்கார பய எல்லத்தையும் Architect பண்ணிட்டான். Code எழுதி முடிச்சாச்சு. இப்ப எழுதுன Code ட எப்படி சரியா Weaving பண்ணுறது. அதுக்குதான் இத்தனை Weaving Techniques இருக்கு.

1) PreProcessor (like C++)
2) PostProcessor (like patching binary files)

The first two options complicate the development process

3) AOP-aware compiler that generates woven binary files (இப்ப இந்த compiler லரத்தான் நோன்டிக்கிட்டு இருக்கேன். நல்லா மண்டை காயுது. என்னா இங்க எதோ பல இடத்தில் Generated Code Change ஆவுது. சாதாரன Code Debugging பண்ணுர விட நிறைய மாறுதல்கள். ( இந்த மரமண்டைக்கு ஒன்னுமே புரியல). இது வரைக்கும் இருந்த Debugging எல்லாம் வேலைக்கு ஆகலை :-( ஒரே லாஜிக் AOP முறையில் எழுதுன Code Profile பண்ணுனா தலைசுத்துது.

4) load-time weaving
5) run-time weaving

The last two options may slow down the program's execution. The last option (run-time weaving) also requires a special aspect-aware execution environment. In the world of Java, this implies a special JVM or other supporting framework.

AOP ல இருக்குற பிரச்சனைகள்

1) Debugging - மண்டை சுத்தமா ஆகும் ஒன்னுமே இல்லாம:-)

2) தெரியாம / புரியாம WildCard ல வர்ர JointPoints . இத தவிர்க்கணும்னா Codeல கை வைக்குறவன் Program specific Naming COnventions பத்தி நல்லா தெரிஞ்சவனா இருக்கனும்.

இவ்வளவு நேரம் நான் போட்ட பிளேடுல யாருக்காவது AOP பத்தி கொஞ்சமாவது புரிஞ்சா எனக்கு சந்தோசம் தான்.

நாணும் இப்பத்தான் AOP பத்தி படிச்சிகிட்டு இருக்கேன்..தப்பு இருந்தா சொல்லுங்க. கரெக்சன் பண்ணிக்குவேன்.. யாரவது அறிவாளி Compiler working (weaving) பத்தி எனக்கு புரியும் படி சொன்னா சிரம் தாழ்த்தி கேட்டுகுவேன்.