Showing posts with label not so obvious. Show all posts
Showing posts with label not so obvious. Show all posts

Monday, July 16, 2007

State-Machine Workflow Part II

We have the following on the host app:
  1. A service class that implements communication-service interface
  2. The workflow runtime and its services which are instantiated and added respectively in the host app.
Service Class
The service class basically implements the communication-service interface, promising the interface that it understands which events the workflow would support and that it will raise them. For each of the events that is supported the service class just raises them. That's it!

Workflow Runtime
We come to the centre of the pizza! Workflow runtime is the actual component that hosts the workflow. In effect, it's the translator between the workflow and the rest of the world.

Many services can be registered while instantiating the runtime. Services for External Data Exchange, tracking etc (the list of services can be easily googled) are provided to add extra functionality to the bare-bone runtime. But it's very important to choose the services judiciously as a service without purpose brings down the performance.

Wednesday, July 4, 2007

Going Forward...

Long time that I've updated my blog. I was actually busy with a personal work and couldn't concentrate on this.

Well, as Shakespeare said, All is well that ends well, I'm now going to resume my blog. But going forward the posts would be relating to Windows Workflow Foundation (WF), Windows Communication Foudnation (WCF) and Windows Presentation Foundation (WPF) rather than just C#. Though the theme of the posts would be same, "Not So Obvious..."

Monday, March 26, 2007

Every Type is derived from...

A simple question...

Which is the type from which every other type is derived? Think before you look forward!
If you are answer is System.Object, then it's partially correct. The actual answer is System.Object if it's a reference type. If it is a value type then it derives from System.ValueType.

Friday, March 23, 2007

Software and Writing - A Bad Combination!!

For many know that I work in software but few know that I'm into writing too. And since I'm into Dot Net Framework, this is actually a real bad combination, for reasons that I discovered only yesterday.

Not that anything is wrong with software or writing. But both require me to be highly intellectual (of course, which I'm :-)). So my intellectuality is as follows:
class intellectuality
{
attention to detail; //for example
}

Now that I'm an intellectual, software and writing to me would be

class software : intellectuality
{
}

class writing : intellectuality
{
}


And I would become
class individual : software, writing
{
}
a clear example of multiple inheritence (Mind you! dot net framework doesn't allow this and "why" is what I'll try to address).

Now, I have a software class and a writing class defining me. And each of these two classes are, in turn, defined by one intellectuality class each. When we create an instance of "individual" class, instances of "writing" and "software" are implicitly created. And since writing derives from "intellectuality" an instance of "intellectuality" is also created. Same happens for software also. So, two intellectuality classes, one writing class and one software class define me.

Now where is all this (intellectuality) going to? Since all this, yet, doesn't make any sense, let's drill into it lil' more and see if this is of any use (otherwise you can always leave your brickbats in comments).

First problem here is, though I'm an individual with ability to code and write and strong intellectual skills, I'm being represented by two intellectual classes and not one. Mind you! I'm an intellect. i.e. Since "individual" derives from "writing" and "software", it should essentially have 3 base classes (writing, software and intellectuality) but it has 4 base classes (writing, software and two intellectuality classes).

Second, if I had to use my "attention to detail" ability from my "intellectuality", I do not know which one of the two intellectuality classes to make use of! Should I make use of intellectuality class of writing or of software? (personally I would prefer writing :-)) i.e. if we had to use a method or property of the base class "intellectuality" the runtime doesn't know from which instace to refer to (we have 2 instances created)!

Third, let's say I want to fill in my "intellectuality" with abilities in my "individual". So, I do
intellectuality intellect = new individual();
I'm essentially creating a base class as an instance of child class.
We have problems here. As we have already seen, "individual" ends up having two "intellectuality" sub classes and hence the compiler doesn't know which "intellectuality" object I'm trying to refer to!

These seem to be the "not so obvious" reasons for dot net framework banning Multiple Inheritence. This is also called as the "Diamond" problem. And as far as my life is concerned, it's far more simple and easier and, of course, devoid of "Diamond"(s)!!! :-) :-)