A new aspect to programming?

There's a small but determined group in the coding community who are only half joking when they declare that real coders write their own device drivers because doing anything else is lazy, technologically unsound, and unnecessarily risky. At the other end of the software spectrum are advocates of new techniques like Aspect Oriented Programming (AOP), who are 100 percent serious when they say that real coders want to be as productive as possible so they can keep their jobs, be more productive and re-use code efficiently rather than re-invent the wheel every day of their working lives.

Where did AOP come from?

For many years, object orientation (OO) was the vanguard of this movement, but even OO's idea of creating discrete pieces of code for different functions did not mean that coders were freed from re-writing some parts of an application over and over again. Researchers at the famed Xerox Palo Alto Research Lab (PARC) were examining the limitations of OO in the early 1990s and explored the idea of new ways programming languages might help programmer productivity by easing modularisation of code. At around the same time, then PhD student Cristina Lopes and others at Northeastern University in the USA were pursuing similar thinking. Eventually, the USA's Defense Advanced Research Projects Agency (DARPA) noticed the work, injected funding and encouraged collaboration between PARC and Northeastern, who combined to create Aspect J, a set of extensions to Java that programmers can now use to apply AOP.

AOP's core idea is "separating the business logic in an application from the common services that support it," according to Adam Magee, a Senior Solution Architect with Avanade, a technology integrator that specialises in Microsoft technologies. AOP practitioners call those common services "crosscutting concerns," as the functionality they offer cuts across the needs of many objects in an application.

"Cross-cutting concerns could be instrumentation, auditing, logging, security checks or exception handling," says Magee, who has applied AOP to many projects. "Writing code to interface with these services can be very time consuming and it can take a developer a long time to do it. It also distracts them from solving the business problem-which is where the value is-and diverts them to delving around inside complex operating system plumbing

Benefits

AOP aims to get around these problems by separating the job of writing cross-cutting concerns-also known as "aspects', from the job of writing objects that comprise business logic, then offering structures so that an application can simply use the functions of aspects without needing to rebuild or recode anything at all.

The technique aims to save time by allowing developers to create a definition of the cross-cutting concerns an application requires to suit every object that requires it. So instead of, for example, writing a logging system for each object-a practice AOP characterises as "scattering"--AOP practitioners would suggest that during the design phase of a project, developers should define the logging requirements for every object with the application and then create a single logging tool that performs all the logging functions that will ever be required by any part of the application.

AOP's proponents say the benefits of this approach are several. Firstly, the effort that goes into defining all of an application's requirements for a service like logging means the services are better-defined, better-coded and emerge offering richer functionality. It also addresses problems created when code is written to perform more than one function, as changes to one function can impact the other, a problem AOP dubs "tangling. Secondly, making the effort to create discrete aspects allows a development team to assign an expert to the job, so that the best people for the job can exercise their skill and experience.

A third benefit is consistency. In a typical object-oriented project different coders will often start with the same code to create a service like logging, then each diverge in their individual implementations of the logging services required to support an individual object. By creating a single piece of code, AOP offers a simple route to consistency, which enhances future re-usability and eases maintenance: Instead of re-writing logging routines throughout an application AOP makes it possible to re-write just the logging aspect and have the new functionality serve the entire application. All of these benefits reduce the number of lines of code that need to be written, saving time, controlling costs and freeing resources for more valuable activities than writing a logging program.

AOP at work

"Traditionally when you design an application you start by defining the business functions: all the things you need the

Technical Analysis

COM programmers build their software using COM-aware components. Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers, or GUIDS. Each COM component exposes its functionality through one or more interfaces. The different interfaces supported by a component are distinguished from each other using interface IDs (IIDs), which are also GUIDS. COM interfaces have bindings in several languages, such as C, C++, D, Visual Basic, and several of the scripting languages implemented on the Windows platform. All access to components is done through the methods of the interfaces. This allows techniques such as inter-process, or even inter-computer programming (the latter using the support of DCOM).

All COM components must (at the very least) implement the standard IUnknown interface. Indeed, all COM interfaces are derived from the IUnknown interface. The IUnknown interface consists of three methods: AddRef () and Release (), which implement reference counting and control the lifetime of interfaces; and QueryInterface, which by specifying an IID allows a carer to retrieve references to the different interfaces the component implements. The effect of QueryInterface () is similar to dynamic-cast<> in C++ or casts in D, Java and C#.

COM specifies many other standard interfaces used to allowed inter-component communication. For example, one such interface is IStream, which is exposed by components that have data stream semantics (e.g. a FileStream component used to read or write files). It has the expected Read and Write methods to perform stream reads and writes. Another standard interface is IOleObject, which is exposed by components that expect to be linked or embedded into a container. IOleObject contains methods that allow callers to determine the size of the component s bounding rectangle, whether the component supports operations like 'Open', 'Save' and so on.

A running instance of a component can be obtained by asking the COM runtime library for a class factory and specifying the CLSID of the required component. The returned class factory is then asked to create an instance of the desired component, specifying an UD to obtain a particular interface that the component implements. A client then calls interface methods, and finally releases the interface by calling the Release () method.

Components can describe themselves using COM Type Libraries. A type library contains information such as the CLSID of a component, the IIDs of the interfaces the component implements, and descriptions of each of the methods of those interfaces. Type libraries are typically used by RAD environments such as Visual Basic or Visual Studio to assist in the programming of COM components.

COM programmers are responsible for entering and leaving the COM environment, instantiating and reference counting COM objects, querying objects for version information, coding to take advantage of advanced object versions, and coding graceful degradation of function when newer versions aren't available. COM classes are identified by a Globally Unique Identifier or GUID--a 128-bit number--guaranteed unique worldwide. COM classes must be listed by number in The Registry. COM objects may be referenced from within a process, across process boundaries within a computer, and across a network. A COM object watches its reference count and causes itself to disappear once the reference count goes to zero. Vast amounts of software have been written using COM. There is much visible plumbing involved with COM, especially for C++ programmers. The Microsoft.NET framework puts the plumbing in the walls.

www.wickipedia.com