1 / 17

Framework Design

General Design Goals. SimpleEasy to learn and use.Code writing using API is easy to read and maintain.Does not have any novel design ideas.Integrate easily with other toolsIDEs (auto-completion, design-mode).Widely used frameworks (Spring.NET, CSLA.NET, Nhibernate, AJAX toolkit)Other develop

faustus
Download Presentation

Framework Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. Framework Design How to Design Good API

    2. General Design Goals Simple Easy to learn and use. Code writing using API is easy to read and maintain. Does not have any novel design ideas. Integrate easily with other tools IDEs (auto-completion, design-mode). Widely used frameworks (Spring.NET, CSLA.NET, Nhibernate, AJAX toolkit) Other development tools (ODP.NET) Consistent Member names are the same wherever possible. Parameter positions are the same whenever possible. Simplifies the learning curve of new parts of the framework.

    3. General Design Goals Easy to evolve into future versions New features, updates, customer requests, etc. Once something is in the API it will stay there and continue to work. You can’t anticipate what users will do with your API. Testable The framework itself can be unit tested easily. Applications written using the framework can be unit tested easily.

    4. Keeping Things Simple Scenario-based/use-case design. Start with the top scenarios. Ask other developers to writing code based on how they want to use your framework. Write code samples to support scenarios. Define your object model to support the top scenarios/samples. Self-documenting API. Allow developers to use it immediately. Minimize initialization: Developers should be able to use it immediately. Provide default values for properties and parameters whenever possible.

    5. Keeping Things Simple Keep in mind your customers’ development knowledge. Minimize the learning curve between simple and complex scenarios. VB5, MFC and .NET Limit abstractions in your framework. Do not over design You can always add and never remove. It is better to cut a feature off a release, think it over and include it in the next one. Keep the innovation to the internals API should have a “boring” design. Look at how existing frameworks do it.

    6. System.Messaging.MessageQueue static void Main(string[] args) { MessageQueue mq = new MessageQueue(@".\private$\msmqTest"); mq.Send("Hello World"); }

    7. Keeping Things Consistent Naming Microsoft’s Naming Guidelines Top scenarios should have the intuitive names. Do not be afraid to be verbose. Use a spell checker! Calcolate(), GetMorgageRate(), GetEmployeeInformations() GetGridColums(), DadaBind(), Re-solveEmailAddress()

    8. Keeping Things Consistent Keep your API similar to what the customer is familiar with For .NET do not add a “LoadData()” method. Use the “DataSource” and “DataBind()” instead. Keep member names the same wherever possible. Keep parameter ordering the same whenever possible. For example, SqlConnection is always the 1st parameter to the method.

    9. Simplifying The Learning Curve Most developers treat documentation as “reference only”. Learn by example/experimentation. Entry level (your API 101) should be the top scenarios. Should be able to write 3 lines example and use 1 object. Strong Typing Customer.Name vs. Customer.Properties[“Name”] SendMsg(body, true) vs. SenMsg(body, UseEncryption.Yes) Communicate correct usage through exception messages.

    10. Simplifying The Learning Curve

    11. Extensibility Mechanisms Various mechanisms with different cost & benefits. Unsealed classes Protected class members Events and callbacks Abstract classes and interfaces Base classes Sealed classes

    12. Architecture and Design Patterns Layered Architecture Low-Level API (more power/control. Example: Sockets). High-Level API (more simplicity/usability. Example: HttpRequest). Factor your API based on level Expose layers through separate namespaces/sub-namespaces. System.Web (Low-Level: HttpRuntime, HttpApplicationState). System.Web.UI (High-Level: Page, Control)

    13. Façade Design Pattern Provides a simplified interface to a larger body of code.

    14. Façade Design Pattern Usually used to aggregate Low-Level API into High-Level API to support the common scenarios. Email class ties SMTP, Sockets, Encodings, etc. Hides the complexity of the implementation. Façade components should not be required to implement any interfaces. Always provide default implementations to keep things simple. Create-Set-Call.

    15. Asynchronous Patterns Classic Async Pattern (a.k.a Async Pattern). Optimized for power and flexibility. Usually executed on an arbitrary thread. Delegate-based. Event-Based Async Pattern (a.k.a Async Pattern for Components). Optimized for usability and integration with visual designers. Usually executed on a thread appropriate to the application model (UI thread for Windows Forms).

    16. Questions?

    17. Resources & Further Reading Microsoft's design guidelines for developing class libraries http://msdn.microsoft.com/en-us/library/ms229042.aspx Framework Design Guidelines: Convention, Idioms and Patterns for Reusable .NET Libraries. (ISBN: 0321545613) Practical API Design: Confessions of a Java Framework Architect (ISBN: 1430209739)

More Related