22
EXTENSIBILITY: SOFTWARE THAT SURVIVES Miguel A. Castro [email protected]

Extensibility - Software That Survives - Miguel A. Castro

Embed Size (px)

Citation preview

Page 1: Extensibility - Software That Survives - Miguel A. Castro

EXTENSIBILITY:SOFTWARE THAT SURVIVES

Miguel A. Castro

[email protected]

Page 2: Extensibility - Software That Survives - Miguel A. Castro

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

Page 3: Extensibility - Software That Survives - Miguel A. Castro

Agenda

• Extensibility – Why/What ?• Patterns• References

Page 4: Extensibility - Software That Survives - Miguel A. Castro

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

Page 5: Extensibility - Software That Survives - Miguel A. Castro

Offloading Concrete Decisions

• Defining abstractions of what’s needed

• Give the ability to assign variety of concreteness

• Remove concrete implementations from host

Page 6: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 7: Extensibility - Software That Survives - Miguel A. Castro

Extensibility Jargon

• Strategy Pattern

• Plug-In Architecture

• Provider Model

• Dependency Injection

• Inversion of Control

• Chain of Responsibility

• Interception Events

Page 8: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 9: Extensibility - Software That Survives - Miguel A. Castro

• Question to be asked:

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

Providers

Page 10: Extensibility - Software That Survives - Miguel A. Castro

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

Page 11: Extensibility - Software That Survives - Miguel A. Castro

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.)

Page 12: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 13: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 14: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 15: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 16: Extensibility - Software That Survives - Miguel A. Castro

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

Page 17: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 18: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 19: Extensibility - Software That Survives - Miguel A. Castro

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 + & -.

Page 20: Extensibility - Software That Survives - Miguel A. Castro

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.

Page 21: Extensibility - Software That Survives - Miguel A. Castro

• 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

Page 22: Extensibility - Software That Survives - Miguel A. Castro

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