ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo
EXTENSIBILITY: SOFTWARE THAT SURVIVES Miguel A. Castro [email_address]
?
Agenda Extensibility ¨C 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.
Providers Question to be asked: What do you need to send in and what do you need to get out.
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
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. 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
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.
References Patterns of Enterprise Application Architecture   Martin Fowler ¨C Addison-Wesley Head First Design Patterns   Freeman, Bates, & Sierra ¨C O¡¯Reilly C# Design Patterns   Steven John Metsker ¨C Addison-Wesley Refactoring to Patterns   Joshua Kerievsky ¨C Addison-Wesley Agile Principles, Patterns, & Practices in C# *   Martin & Martin ¨C Prentice Hall
DNR TV ¨C Carl Franklin   Writing Plug-Ins   http://www.dnrtv.com/default.aspx?showID=34 Polymorphic Podcast ¨C Miguel A. Castro   Designing for Extensibility   http://www.polymorphicpodcast.com/   shows/architectextensibility SteelBlue Solutions ¨C this presentation   http://www.steelbluesolutions.com Data & Object Factory   http://www.dofactory.com

More Related Content

Extensibility - Software That Survives - Miguel A. Castro

  • 1. EXTENSIBILITY: SOFTWARE THAT SURVIVES Miguel A. Castro [email_address]
  • 2. ?
  • 3. Agenda Extensibility ¨C 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 ¨C Addison-Wesley Head First Design Patterns Freeman, Bates, & Sierra ¨C O¡¯Reilly C# Design Patterns Steven John Metsker ¨C Addison-Wesley Refactoring to Patterns Joshua Kerievsky ¨C Addison-Wesley Agile Principles, Patterns, & Practices in C# * Martin & Martin ¨C Prentice Hall
  • 22. DNR TV ¨C Carl Franklin Writing Plug-Ins http://www.dnrtv.com/default.aspx?showID=34 Polymorphic Podcast ¨C Miguel A. Castro Designing for Extensibility http://www.polymorphicpodcast.com/ shows/architectextensibility SteelBlue Solutions ¨C this presentation http://www.steelbluesolutions.com Data & Object Factory http://www.dofactory.com