Nerdic Canvass

Events vis-a-vis Delegates

2010-08-30T15:25:0005:30:00

Recently, I was involved in a hiring process. And of the many questions that were asked to the candidates during the process, one common question that was asked a lot was:

Difference between Events and Delegates ? And most of the time, i don’t get what I really expect. The essential question, that I am trying to get is,

If I can achieve the same functionality with an delegate, that I desire from an event, and more over the underlying mechanism of the event is a delegate, why has the event keyword been created by Microsoft ?

Lets look at an example Delegate:

This gets converted to something like the following:

Interesting enough, not yet, lets complete the picture after throwing in an event.

Let’s examine the class, DelegateInspector, in reflector.

What’s just happened, just the event declaration generates quite some amount of code around. Now what is the implication of the code above is below.

Hope it helps!

Welcome Back !!!

2010-03-29T16:19:2605:30:00

Well, its been quite sometime since I have been able to post anything significant.Have been quite busy with some personal stuff, which required more immediate attention. Finally, got the time today to log about something.

I have switched companies, I have been cussed about and world seems to have gone awry to awesome for me in the meanwhile.

Any ways, back to my blogging ways again and soon I would be starting a series of blogs about WCF, and Networking stuff.

Till Then,

- Happy Coding!

My tryst with MAPI

2009-12-07T12:35:0305:30:00

For the past two weeks I was up against MAPI. I must admit, its a amazing piece of work and liked it, the more I delved into it.

Let me delve a bit more into the specifics of the problem a bit more.

We have a piece of software, and it is used to synch up contacts across Exchange and a custom application using Mapi Server Client. Now this works fine if the Systems are Exchange Server 2003 on Win2k3, and Our Application is on Windows 2008. But the problem started appearing when we tried the same thing out when the combination is Exchange 2007 on Win2k8 and our application on Win 2k8.

I dug deep and I resorted to aprroach, the only guy who I knew blogs about MAPI - SGriffin. And he did respond and put us on the right track.

If you face same kind of problems that we faced, the things that you need to check is:

There is a issue with with IPv6 - Click Here and Click Here
Ensure that you create the Service Account properly - Click Here
Make sure your user with whom you created your profile is a member of "Exchange Organization Administrator"
Ensure you download and install the latest Exchange MAPI server client

Hope this heps.

Pattern Discussion: Abstract Factory vis a vis Factory

2009-11-12T19:21:5705:30:00

The other day we had a discussion related to the abstract factory and let me tell you, flames flew and it was high on melodrama.

Anyways coming back to the main point, the root of whole discussion was,

A: Why should I use the abstract factory, just for a parallel set of classes, what am I getting out of it ?

B: You are abstracting your product, that's why you are creating it. Apart from that, its a you have a mechanism for creating related set of products, which is important here, you see you should not forget that, its for creating a set of related family of products.

C: But say if you are just creating is two set of components, a UI Components for rich mode and the simple mode, could you not do with a static Factory implementation instead of so much of fun fare? And also if you look closely, what you are doing is essentially now binding your classes to the implementation of the Abstract Factories some where, because to get the code running you have to write the Implementation class some where, so would not it be better if we had just a static factory class which gives us what we need.

B: hmmmm...

A: Apart from that so much of code to manage .... That's a good one C:)

C: Thanks! Man

B: Factory Method defines an interface for creating an object, but lets subclasses decide which of those to instantiate. A factory method lets classes defer instantiation to subclasses.By contrast, an Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes.

C: We have a family of related objects but, ... I don't want to take a purists view or go by book view.. I look at convinience and unless you tell me why, I don't see any reason why I should not go for a Factory than a Abstract Factory here.

A: And if you ask me, I guess you are over complicating, is not this kind of an YAGNI.

B: Well, let me examine the definitions a bit more:

Factory Method defines an interface for creating an object, but lets subclasses decide which of those to instantiate. A factory method lets classes defer instantiation to subclasses.

Which essentially means, in this case the decision is taken by sub class -> Inheritance is in action.

Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes. Now in this case the job of creating the instance of the products are delegated -> Composition in Action.

And as you guys already know Composition allows you to delay the creation of back-end objects until (and unless) they are needed, as well as changing the back-end objects dynamically throughout the lifetime of the front-end object. With inheritance, you get the image of the superclass in your subclass object image as soon as the subclass is created, and it remains part of the subclass object throughout the lifetime of the subclass.

So I would say, if you need it dynamically vary, take the composition route and enjoy the benefits of Abstarct Factory else, Factory should be just fine for you.

C: hmmm..

A: ok

Hope you like the dialogue....:)

Patterns:Factory

2009-11-12T19:18:3805:30:00

Since I have already mentioned Factory in a post, its time we should talk about the same. Factory should get the respect it deserves because its worth it.

Intent

Defines an interface for creating an object, but lets subclasses decide which of those to instantiate.

Scenario

Say we need to implement a way to create Accounts. Now, there are different kinds of Account,

a.) Savings Account - Acts as a Normal, but allows you to withdraw only when you are not taking the balance below the minimum stipulated balance.

a.) i.) Salaried Savings Account - Same as Savings Account but minimum balance can be 0.

b.) Current Account.- Can allow you to go till a -ve balance, only for traders

As you can see, the difference in limit and the difference in Withdrawl Strategies. There are many other business rules, but for the context of the Problem, we would like to keep it simple. But one essential question is, why do we need to think so much, we just need to be able to create Savings Account, Salaried Savings Account and Current Account ?

Well, the bank says we want to keep a hook for bringing in new types of Account in Near future. There you have it, Business as usual. So how do you structure the code, I can think of, I would create an Account Class, where the Deposit would be having a implementation since, its function is just to add money to the account. But as for the Withdraw method I would leave it as abstract, because, it depends on the type of Account you are operating it. Its a stronger relationship.

In this scenarios, we generally prefer the factory pattern where in, if a new type of Account is introduced tommorow, we can easily add a new subclass of the AccountFactory class and bring in support for a new kind of account.

Let me just substantiate, what I just wrote.

So as you can see from the above diagram, the responsibility of creation of CurrentAccount lies in CurrentAccountFactory and like wise for SavingsAccount the SavingsAccountFactory. Say we introduce a new Account Class we just need to introduce a new AccountFactory subclass which will take care of instantiating it properly.

There are two versions of a Factory pattern:

1. Static Factory. There are no subclasses, rather there is a single static method that takes in a parameter and creates a appropriate instance of the product. This works when the frequency of adding a product is low and it can survive a compilation.

2. Instance Factory. This generally works in conjunction with Reflection as in Java/.Net. and this works better when the chances of adding a product is high and we do not want to re-compile the whole code base.