December 2003 - Posts
AOP (Aspect Oriented Programming) is not new to us at all. We all have implicitly embraced AOP by using MTS/COM+. But the sad part is that implementing AOP in COM is an absolute hack (ATL, Universal Delagator etc) and not for humble VB developers like me.
Come .NET, things are definitely brighter. Interception is no more a rocket science and implementing the same is (almost) a piece of cake. The magic is called ContextBoundObject and some Custom attributes. Have a look at this good article which gives AOP implementation for .NET (as well as for COM). As I already mentioned, leave aside the COM part :)
http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx . ContextBound objects allow us to declare aspects of classes declaratively using custom attributes. It is a very very powerful concept indeed.
Attributes on the ServicedComponent class now makes sense. ServicedComponent is just another ContextBound object.
Try these steps and see what happens.
Step 1 : Let's say I have a Base class and an overridable (virtual method). Now, I derive a class from this and override the virtual method.
Step 2 : In both these classes, have the constructor call the virtual method.
Step 3: Create an instance of the derived class using the base class reference. Here's what I mean: dim obj as Base = New Derived()
Now, you have to agree with me that the base class constructor is called before the derived one?? If yes, which method is dispatched in the base class constructor - the method in the base or the method in the derived? Whatever be the answer - why would it happen this way?
The answer to the "which" part of the question is - the derived class method is dispatched.
This can have interesting consequences - You can end up invoking an instance method of an object before its constructor !!!! So what happens if you access instance members Inside that virtual method? Answer - Catastrophe!. But it is okay. It takes a genius to do this extraordinarily stupid thing. We are just normal developers. Aren't we ??
The finalizer method is often mistaken to be the destructor of the managed world. That is exactly not the case. Well, a destructor and a finalizer, both of them are the last points of any instance related cleanup. The similarity ends here.
A destructor (I was talking about the C++ one here), is a method automatically called when an object goes out of scope or when the delete operator is called upon the object pointer. A finalizer, on the other hand, is a method called automatically alright, but this happens only when garbage collection kicks in. This ofcourse, need not happen immediately when an object goes out of scope. A GC happens only on demand- when memory needs to be reclaimed from the managed heap.
- Using interface references, you can access private methods of a class. That is, if your class has got any private methods which in turn are a part of an interface implementation, then they can be accessed using interface references. If you recollect, the interface definition does not include access specifiers.
- Interface references can also be used on Value types (structures etc). But note that, the methods would be called on the boxed version of the values.
Being an average VB developer, I have stayed aloof from core OS concepts or Win32 API for that matter. Yesterday afternoon, I was casually browsing through the Caching App block and that is where I stumbled into MMFs. Honestly, MMFs are not totally an alien concept altogether. We all know bits about what a Paging file is - it is a file used by our OS to swap contents to and from the memory (demand paging). In essence, it is memory mapped. I was surprised to know that all executable files (exes, DLLs) are memory mapped too! Only that here, code pages are swapped to and fro from these binary images. So, while executable file is to code pages, the Page file is to Data pages.
So, mapping the contents of a file to some memory addresses in your process is all about MMFs are. So, what's the deal, how are MMFs useful? Well I could understand two uses:
- Sharing data between processes - I believe MMFs can be extended to include parts of the system page file, thereby enabling two or more processes to share data.
- Reading and writing to a very large file - If a very large file is memory mapped, then only required contents can be demand paged, thereby providing a better option than buffering all the file contents in memory. So, now I can guess how DBMS manages huge datafiles!
Creating and using MMFs is not overly simple and require the usage of some grunge Win32 API. But fortunately, the caching app block provides a good managed wrapper for the same and can be used as a reference.
This was the great article that threw some light on MMFs: Managing Memory-Mapped Files in Win32. It was published way back in 93, but I believe everything will hold in today's systems too!