extensibility - software that survives - miguel a. castro

EXTENSIBILITY:SOFTWARE THAT SURVIVES

Miguel A. Castro

miguel.castro@idesign.net

ineta

.NET Architect, Developer, & Trainer Microsoft MVP ASP Insider Member of the INETA Speakers Bureau Conference Speaker Creator of CodeBreeze In IT business since 1986

Your Speaker

Agenda

• Extensibility – Why/What ?• Patterns• References

Extensibility

• About planning for the future

• Anticipating where mods and/or enhancements will be needed or desired

• Offloads concrete decisions• Data sources, processing, etc.

• Offering alternatives in your application

Offloading Concrete Decisions

• Defining abstractions of what’s needed

• Give the ability to assign variety of concreteness

• Remove concrete implementations from host

Implemented In Any Layer

• Data Layer– Data providers determine where and how to get

data.

• Business Layer– Plug-in processes and modules– Providers patterns & Dependency Injection

• Presentation Layer– Data-driven forms and Web Control templates as

well as plug-in processes and modules.– Plug-in and out forms.

Extensibility Jargon

• Strategy Pattern

• Plug-In Architecture

• Provider Model

• Dependency Injection

• Inversion of Control

• Chain of Responsibility

• Interception Events

Providers

• Provide abstracted communication between a host and more than one dependency.

• Based on the Strategy Pattern.

• When used with a builder, is a form of dependency injection.

• At the heart of ADO.NET’s design.

• Question to be asked:

What do you need to send inand what do you need to get out.

Providers

Before

After

1. Determine file name2. Get file data3. Log data to another file

1. Determine data source2. Get data3. Log data to destination

Intent: Client needs string data to be passed in then out

Providers

Plug-Ins

• Add functionality to processes without altering host

• Accommodates enhancing at later date by inserting running points

• Allows swapping of functionality

• Can be used to swap out core functionality(i.e. record saving, etc.)

Plug-Ins• Interface defines method that receives and

returns necessary data.

• Classes implement interface and provide behavior upon data (in & out).

• List of classes defined (config).

• Host reads in list, “activates” each and casts to interface.

• Interface method executed.

Modules

• Similar to the concept of a plug-in.

• Defines multiple points of extensibility in one class.

• Can be used in place of standard plug-ins.

• Provides logical groupings of extensibility functionality.

Modules

• Other names:• Filters• Interception Events• Chain of Responsibility

• Gives developers one place to go to write a plug-in.

• Pattern used by HTTP Modules.

Form Substitution

• Abstracts interaction between Windows Forms.

• Abstraction defines in & out for a form.

• Developers can design and inject a new form later.

• Pattern essentially the same as Providers.

Form Substitution

Intent: Form needs to obtains customer info from another

What we’re NOT going to do

Obtain a customer object from a customer entry form using conventional instantiation.

1. Use a provider model to determine form to use.

2. Interface or base for usage.

3. Use an entry-point method for entering form.

What we ARE going to do

Advanced Technique

• Plug-ins and modules can avoid declarative meta-data (configuration).

• Use attributes to describe implementation classes.

• Specified folder holds assemblies.

• Builder object reads through assemblies & types.

• Attribute info can determine order.

Things To Remember

• Think about points of extensibility as you design.

• Consider turning concrete processes into extensibility implementations.

• Use abstraction whenever possible.

• provides ground work for extensibility

• promotes decoupling

• Providers can be used at the Form level.

Things To Remember

• Binaries for extensibility components need to reside in host’s Bin folder, but not necessarily in the references.

• Must use your own judgment to deter- mine where to insert extensibility points and where to use provider-type objects.

• There may be performance implications. Like everything, weight out + & -.

Things To Remember

• Don’t be afraid to refactor into these patterns later

• Don’t get caught in analysis-paralysis

• “Resisting the urge to abstract too early is as important as the abstractions” *

• May need to plan a rollback mechanism for failed plug-ins.

• Plan for malicious plug-ins or providers.

• Patterns of Enterprise Application Architecture Martin Fowler – Addison-Wesley

• Head First Design Patterns Freeman, Bates, & Sierra – O’Reilly

• C# Design Patterns Steven John Metsker – Addison-Wesley

• Refactoring to Patterns Joshua Kerievsky – Addison-Wesley

• Agile Principles, Patterns, & Practices in C# * Martin & Martin – Prentice Hall

References

References

www.dotnetdude.comwww.steelbluesolutions.com

• DNR TV – Carl Franklin Writing Plug-Ins http://www.dnrtv.com/default.aspx?showID=34

• Polymorphic Podcast – Miguel A. Castro Designing for Extensibility http://www.polymorphicpodcast.com/ shows/architectextensibility

• SteelBlue Solutions – this presentation http://www.steelbluesolutions.com

• Data & Object Factory http://www.dofactory.com