Extensibility - Software That Survives - Miguel A. Castro


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Extensibility - Software That Survives - Miguel A. Castro

  1. 1. EXTENSIBILITY: SOFTWARE THAT SURVIVES Miguel A. Castro [email_address]
  2. 3. Agenda <ul><li>Extensibility – Why/What ? </li></ul><ul><li>Patterns </li></ul><ul><li>References </li></ul>
  3. 4. Extensibility <ul><li>About planning for the future </li></ul><ul><li>Anticipating where mods and/or enhancements will be needed or desired </li></ul><ul><li>Offloads concrete decisions </li></ul><ul><ul><li>Data sources, processing, etc. </li></ul></ul><ul><li>Offering alternatives in your application </li></ul>
  4. 5. Offloading Concrete Decisions <ul><li>Defining abstractions of what’s needed </li></ul><ul><li>Give the ability to assign variety of concreteness </li></ul><ul><li>Remove concrete implementations from host </li></ul>
  5. 6. Implemented In Any Layer <ul><li>Data Layer </li></ul><ul><ul><li>Data providers determine where and how to get data. </li></ul></ul><ul><li>Business Layer </li></ul><ul><ul><li>Plug-in processes and modules </li></ul></ul><ul><ul><li>Providers patterns & Dependency Injection </li></ul></ul><ul><li>Presentation Layer </li></ul><ul><ul><li>Data-driven forms and Web Control templates as well as plug-in processes and modules. </li></ul></ul><ul><ul><li>Plug-in and out forms. </li></ul></ul>
  6. 7. Extensibility Jargon <ul><li>Strategy Pattern </li></ul><ul><li>Plug-In Architecture </li></ul><ul><li>Provider Model </li></ul><ul><li>Dependency Injection </li></ul><ul><li>Inversion of Control </li></ul><ul><li>Chain of Responsibility </li></ul><ul><li>Interception Events </li></ul>
  7. 8. Providers <ul><li>Provide abstracted communication between a host and more than one dependency. </li></ul><ul><li>Based on the Strategy Pattern. </li></ul><ul><li>When used with a builder, is a form of dependency injection. </li></ul><ul><li>At the heart of ADO.NET’s design. </li></ul>
  8. 9. Providers <ul><li>Question to be asked: </li></ul><ul><ul><li>What do you need to send in and what do you need to get out. </li></ul></ul>
  9. 10. Providers Before After <ul><li>Determine file name </li></ul><ul><li>Get file data </li></ul><ul><li>Log data to another file </li></ul><ul><li>Determine data source </li></ul><ul><li>Get data </li></ul><ul><li>Log data to destination </li></ul>Intent: Client needs string data to be passed in then out
  10. 11. Plug-Ins <ul><li>Add functionality to processes without altering host </li></ul><ul><li>Accommodates enhancing at later date by inserting running points </li></ul><ul><li>Allows swapping of functionality </li></ul><ul><li>Can be used to swap out core functionality (i.e. record saving, etc.) </li></ul>
  11. 12. Plug-Ins <ul><li>Interface defines method that receives and returns necessary data. </li></ul><ul><li>Classes implement interface and provide behavior upon data (in & out). </li></ul><ul><li>List of classes defined (config). </li></ul><ul><li>Host reads in list, “activates” each and casts to interface. </li></ul><ul><li>Interface method executed. </li></ul>
  12. 13. Modules <ul><li>Similar to the concept of a plug-in. </li></ul><ul><li>Defines multiple points of extensibility in one class. </li></ul><ul><li>Can be used in place of standard plug-ins. </li></ul><ul><li>Provides logical groupings of extensibility functionality. </li></ul>
  13. 14. Modules <ul><li>Other names: </li></ul><ul><ul><li>Filters </li></ul></ul><ul><ul><li>Interception Events </li></ul></ul><ul><ul><li>Chain of Responsibility </li></ul></ul><ul><li>Gives developers one place to go to write a plug-in. </li></ul><ul><li>Pattern used by HTTP Modules. </li></ul>
  14. 15. Form Substitution <ul><li>Abstracts interaction between Windows Forms. </li></ul><ul><li>Abstraction defines in & out for a form. </li></ul><ul><li>Developers can design and inject a new form later. </li></ul><ul><li>Pattern essentially the same as Providers. </li></ul>
  15. 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. <ul><li>Use a provider model to determine form to use. </li></ul><ul><li>Interface or base for usage. </li></ul><ul><li>Use an entry-point method for entering form. </li></ul>What we ARE going to do
  16. 17. Advanced Technique <ul><li>Plug-ins and modules can avoid declarative meta-data (configuration). </li></ul><ul><li>Use attributes to describe implementation classes. </li></ul><ul><li>Specified folder holds assemblies. </li></ul><ul><li>Builder object reads through assemblies & types. </li></ul><ul><li>Attribute info can determine order. </li></ul>
  17. 18. Things To Remember <ul><li>Think about points of extensibility as you design. </li></ul><ul><li>Consider turning concrete processes into extensibility implementations. </li></ul><ul><li>Use abstraction whenever possible. </li></ul><ul><ul><li>provides ground work for extensibility </li></ul></ul><ul><ul><li>promotes decoupling </li></ul></ul><ul><li>Providers can be used at the Form level. </li></ul>
  18. 19. Things To Remember <ul><li>Binaries for extensibility components need to reside in host’s Bin folder, but not necessarily in the references. </li></ul><ul><li>Must use your own judgment to deter- mine where to insert extensibility points and where to use provider-type objects. </li></ul><ul><li>There may be performance implications. Like everything, weight out + & -. </li></ul>
  19. 20. Things To Remember <ul><li>Don’t be afraid to refactor into these patterns later </li></ul><ul><ul><li>Don’t get caught in analysis-paralysis </li></ul></ul><ul><ul><li>“ Resisting the urge to abstract too early is as important as the abstractions” * </li></ul></ul><ul><li>May need to plan a rollback mechanism for failed plug-ins. </li></ul><ul><li>Plan for malicious plug-ins or providers. </li></ul>
  20. 21. References <ul><li>Patterns of Enterprise Application Architecture Martin Fowler – Addison-Wesley </li></ul><ul><li>Head First Design Patterns Freeman, Bates, & Sierra – O’Reilly </li></ul><ul><li>C# Design Patterns Steven John Metsker – Addison-Wesley </li></ul><ul><li>Refactoring to Patterns Joshua Kerievsky – Addison-Wesley </li></ul><ul><li>Agile Principles, Patterns, & Practices in C# * Martin & Martin – Prentice Hall </li></ul>
  21. 22. <ul><li>DNR TV – Carl Franklin Writing Plug-Ins http://www.dnrtv.com/default.aspx?showID=34 </li></ul><ul><li>Polymorphic Podcast – Miguel A. Castro Designing for Extensibility http://www.polymorphicpodcast.com/ shows/architectextensibility </li></ul><ul><li>SteelBlue Solutions – this presentation http://www.steelbluesolutions.com </li></ul><ul><li>Data & Object Factory http://www.dofactory.com </li></ul>