Extensibility - Software That Survives - Miguel A. Castro

Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. EXTENSIBILITY: SOFTWARE THAT SURVIVES Miguel A. Castro [email_address]
  • 2.  
  • 3. Agenda
    • Extensibility – Why/What ?
    • Patterns
    • References
  • 4. 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
  • 5. Offloading Concrete Decisions
    • Defining abstractions of what’s needed
    • Give the ability to assign variety of concreteness
    • Remove concrete implementations from host
  • 6. 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.
  • 7. Extensibility Jargon
    • Strategy Pattern
    • Plug-In Architecture
    • Provider Model
    • Dependency Injection
    • Inversion of Control
    • Chain of Responsibility
    • Interception Events
  • 8. 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.
  • 9. Providers
    • Question to be asked:
      • What do you need to send in and what do you need to get out.
  • 10. Providers Before After
    • Determine file name
    • Get file data
    • Log data to another file
    • Determine data source
    • Get data
    • Log data to destination
    Intent: Client needs string data to be passed in then out
  • 11. 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.)
  • 12. 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.
  • 13. 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.
  • 14. 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.
  • 15. 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.
  • 16. 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.
    • Use a provider model to determine form to use.
    • Interface or base for usage.
    • Use an entry-point method for entering form.
    What we ARE going to do
  • 17. 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.
  • 18. 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.
  • 19. 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 + & -.
  • 20. 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.
  • 21. References
    • 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
  • 22.
    • 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