This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: Limiting the Scope and Abilities of Objects
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
As part of my quest to define and create the smallest Framework, I have come across a feature that is sorely lacking in the Framework space. A Framework should have its own rules, succinct and distinct from standard development and by that I mean that sometimes the functions we need for Frameworks are over and above, under or below everyday development.
Declare a component, library, objects or Assemblies, "As a Framework"
I would like to declare with Java Annotations, c# Attributes, that a defined set of code is a Framework, is part of a Framework. This would give it distinction. Behaviour can then be tailored for a Framework.
in c#, [assembly:FrameworkAssembly()], [class:FrameworkExtensionClass], [interfaces/members:FrameworkExtensionPoint]
Declaring Limitations
Take for example configuration. Currently there is no limitation on any class consuming any configuration it wants. This is because closing it off in the real world, makes no sense.
However, If I have a plug-in, which the Framework instantiates and invokes, it may want to to pass it configuration options. The fact that the plug-in writer has no idea that the Framework wants to do so, unless they are very familiar with the system, and it is clearly marked on an Interface. However, being marked on an Interface is still no guarantee.
So I think there needs to be a way to limit the plug-in. By limiting its capabilities, I am giving the plug-in developer direct communication of the intent.
So if the intent is for plug-ins to utilize the configuration framework, all components implementing IPlugIn, would be stopped from using any other configuration.
In .NET, perhaps its a simple Attribute we mark on the IPlugIn interface,
[FrameworkLimitedTo("Configuration", typeof(Framework.IConfiguration))]
Perhaps it could be more namespace driven as in.
[FrameworkConstraint("System.Configuration", Refuse | Deny | Allow | Limit)]
Now any usage of the System.Configuration would cause a Warning or Compiler Error depending on the Constraint.
Consider Status
A small example. Take a simple Command Pattern. We call execute and during Execute we would like to mark a status. A status of the actual Execute method executing. So when Execute is called the first line is Status = Busy, and the last line is Status = Ready.
How do you enforce that the Execute method of the object you are about to call, actually implements it?
You won't, unless you mark it with yet another Interface, perhaps IImplementsStatus, but even then you have no guarantee that the object is actually setting the Status flag properly.
So towards a fix, a [FrameworkConstraint:VariableStatus(mustBeSet=True)] can be placed on the Execute method.
Previous Topic
