Extensibility pattern

Extensibility pattern

In computer programming, the extensibility pattern is a design pattern that provides a framework for straightforward addition of functionality to a system at a later date.

Extensibility is often desired when an application must be able to support new features, such as networking protocols or file formats, that do not yet exist. This requires the application to supply a framework for the general problem without concern for the specifics of details.

Frameworks

A framework uses other modules. Normal modules have a fixed set of dependencies, and are only extended through subclassing, as per inheritance. A framework may consist of several parts that must be inherited to be used much like several cases of abstract class. It may also be passed references to other objects, as would a class that is sets up a model-view-controller. It may read names of classes from a configuration file or from the user, as in BeanPattern. Instead of code being used by other code, it will use other code on the fly. It is on top of the food chain instead of the bottom.

Configuration files as extensions

A ConfigFile may be enough to customize the module for reasonable needs. It may also specify modules by name to be created and employed in a framework.

# the config.pl file defines @listeners to contain a list of class names # that should receive notices from an EventListener broadcaster, # referenced by $broadcaster.

require 'config.pl';

foreach my $listener (@listeners) { require $listener; my $list_inst = $listener->new(); $broadcaster->add_listener($list_inst); }

See Event listener for the broadcaster/listener idiom. This avoids building the names of listener modules into the application. An independent author could write a plugin to this application: she would need only have the user modify //config.pl// to include mention of the plugin. Of course, modification of //config.pl// could be automated. The install program for the plugin would need to ask the user where the //config.pl// is, and use the ConfigFile idiom to update it.

Extending through scripting

A major complaint against GUIs is that they make it difficult to script repetitive tasks. Command line interfaces are difficult for most humans to work with. Neither give rich access to the application programming interface (API) of a program. A well-designed program is a few lines of Perl in the main program that use a number of modules — see Creating CPAN Modules. This makes it easier to reuse the program logic in other programs. Complex programs that build upon existing parts benefit from this, without question. How about the other case — a small script meant to automate some task? This requires that the script have knowledge about the structure of the application — it must know how to assemble the modules, initialize them, and so on. It is forced to work with aspects of the API that it almost certainly is not concerned with. It must itself be the framework.

This is a kind of abstraction inversion — where something abstract is graphed onto something concrete, or something simple is grafted onto the top of something complex.

It would make more sense in this case for the application to implement a sort of visitor pattern, and allow itself to be passed whole, already assembled, to another spat of code that knows how to perform specific operations on it. This lends itself to the sequential nature of the script: the user-defined extension could be a series of simple calls:

package UserExtention1;

# we are expected to have a "run_macro" method

sub run_macro { my $this = shift; my $app = shift;

$app->place_cursor(0, 0); $app->set_color('white'); $app->draw_circle(radius=>1); $app->set_color('red'); $app->draw_circle(radius=>2); # and so on... make a little bull's eye

return 1; }

The main application could prompt the user for a module to load, or load all of the modules in a plugins directory, then make them available as menu items in an "extensions" menu. When one of the extensions are select from the menu, a reference to the application — or a facade pattern providing an interface to it — is passed to the run_macro() method of an instance of that package.

Many applications will have users that want to do simple automation without being bothered to learn even a little Perl (horrible but true!). Some applications (like Mathematica, for instance) will provide functionality that does not cleanly map to Perl. In this case, you would want to be able to parse expressions and manipulate them. In these cases, a Little Language may be just the thing.

A Little Language is a small programming language, created specifically for the task at hand. It can be similar to other languages. Having something clean and simple specifically targeted at the problem can be better solution than throwing an overpowered language at it. Just by neglecting unneeded features, user confusion is reduced.

place_cursor(0, 0) set_color(white) draw_circle(radius=1) set_color(red) draw_circle(radius=2)

A few options exist: we can compile this directly to Perl byte-code, using B::Generate (suitable for integrating legacy languages without performance loss), or we can munge this into Perl and ||eval|| it. Let us turn it into Perl.

# read in the users program my $input = join ", ;

# 0 if we're expecting a function name, 1 if we're expecting an argument, # 2 if we're expecting a comma to separate arguments my $state = 0;

# perl code we're creating my $perl = ' package UserExtention1;

sub run_macros { my $this = shift; my $app = shift; ';

while(1) { # function call name if($state = 0 && $input =~ m{Gs*(w+)s*(}cgs) { $perl .= ' $app->' . $1 . '('; $state = 1;

# a=b style parameter } elsif($state = 1 && $input =~ m{Gs*(w+)s*=s*( [w0-9] +)}cgs) { $perl .= qq{$1=>'$2'}; $state = 2;

# simple parameter } elsif($state = 1 && $input =~ m{Gs*( [w0-9] +)}cgs) { $perl .= qq{'$1'}; $state = 2;

# comma to separate parameters } elsif($state = 2 && $input =~ m{Gs*,}cgs) { $perl .= ', '; $state = 1;

# end of parameter list } elsif(($state = 1 || $state = 2) && $input =~ m{Gs*)}cgs) { $perl .= "); "; $state = 0;

# syntax error or end of input } else { return 1 unless $input =~ m{G.}cgs; print "operation name expected " if $state = 0; print "parameter expected " if $state = 1; print "comma or end of parameter list expected " if $state = 2; return 0; }

}

$perl .= qq< return 1; } >;

eval $perl; if($@) { # display diagnostic information to user }

We're using the G regex metacharacter that matches where the last global regex on that string left off. That let us take off several small bites from the string rather than having to do it all in one big bite. The flags on the end of the regex are:

* g - global - needed for the G token to work
* c - not sure, but it makes g work
* s - substring - treat the entire string as one string. Newlines become regular characters and match whitespace.

Out of context, the string "xyzzy" could be either a parameter or the name of a method to call. The solution is simply to keep track of context: that is where $state comes in. Every time we find something, we update $state to indicate what class of thing would be valid if it came next. After we find a function name and an opening parenthesis, either a hash style parameter or a single, lone parameter, or else a close parenthesis would be valid. We are not even looking for the start of another function [though perhaps we should be. If changed, this in our code, it would allow us to nest function calls inside of each other. We would have to track our level of nesting if we wanted to report errors if there were too many or too few right-parenthesis. Exercise left for the reader.] .

After a parameter, we are looking for either the close parenthesis or another parameter.

Every time we match something, we append a Perl-ized version of exactly the same thing onto $perl. All of this is wrapped in a package and method declaration. Finally, $perl is evaluated. The result of evaluating should be to make this new package available to our code, ready to be called.

Beans as extensions

Hacks as extensions

When a base application, or shared code base, is customized in different directions for different clients, heavy use should be made of template methods and abstract factories, localizing client-specific code into a module or tree of modules under a client-specific namespace, rather than "where it belongs".

References

* The article is originally from Perl Design Patterns Book.


Wikimedia Foundation. 2010.

Игры ⚽ Поможем написать курсовую

Look at other dictionaries:

  • Structural pattern — In Software Engineering, Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities.Examples of Structural Patterns include:* Adapter pattern: adapts one interface for …   Wikipedia

  • Dependency injection — (DI) is a design pattern in object oriented computer programming whose purpose is to improve testability of, and simplify deployment of components in very large software systems. The Dependency Injection pattern involves at least three elements:… …   Wikipedia

  • Nemerle — Paradigm(s) multi paradigm: metaprogramming, functional, object oriented, imperative Appeared in 2003 Designed by Kamil Skalski, Michał Moskal, Prof. Leszek Pacholski and Paweł Olszta at Wrocław University Stable release …   Wikipedia

  • Colony Framework — Developer João Magalhães, Colony Developers and Hive Solutions Stable release 1.0.0 (May 2011) Major implementations Python, JavaScript, Ruby …   Wikipedia

  • Code refactoring — Refactor redirects here. For the use of refactor on Wikipedia, see Wikipedia:Refactoring talk pages. Code refactoring is disciplined technique for restructuring an existing body of code, altering its internal structure without changing its… …   Wikipedia

  • Mach-II — Infobox Software name = Mach II caption = We re Community Driven genre = web application framework developer = [http://www.greatbiztools.com GreatBizTools, LLC] |source model = Open source latest release version = 1.6 Beta latest release date =… …   Wikipedia

  • Language Integrated Query — LINQ redirects here. For the card game, see Linq (card game). Language Integrated Query Influenced by SQL, Haskell Language Integrated Query (LINQ, pronounced link ) is a Microsoft .NET Framework component that adds native data querying… …   Wikipedia

  • Windows PowerShell — Screenshot of a sample PowerShell session …   Wikipedia

  • Portable Document Format — PDF redirects here. For other uses, see PDF (disambiguation). Portable Document Format Adobe Reader icon Filename extension .pdf Internet media type application/pdf application/x pdf application/x bzpdf application/x gzpdf …   Wikipedia

  • Domain engineering — Domain engineering, also called product line engineering, is the entire process of reusing domain knowledge in the production of new software systems. It is a key concept in systematic software reuse. A key idea in systematic software reuse is… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”