The document discusses extensibility in software design and provides patterns and techniques for implementing extensibility. Extensibility means planning for future modifications and enhancements by defining abstractions and offloading concrete decisions. Extensibility can be implemented at different layers, such as the data, business, and presentation layers, using patterns like providers, plug-ins, modules, and form substitution. The document provides examples and recommendations for designing software with extensibility in mind.
1 of 22
More Related Content
Extensibility - Software That Survives - Miguel A. Castro
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