1 / 35

Design Patterns in Practice

Design Patterns in Practice. By Doug, Jeremy, & Mike. What is a design pattern?. A design pattern is a reusable solution to a common problem in software design. A design pattern is not code. A design pattern can vary in scope from very simplistic to an entire system.

scout
Download Presentation

Design Patterns in Practice

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. Design Patterns in Practice By Doug, Jeremy, & Mike

  2. What is a design pattern? • A design pattern is a reusable solution to a common problem in software design. • A design pattern is not code. • A design pattern can vary in scope from very simplistic to an entire system.

  3. The different kinds of patterns • Creational • Patterns that focus on object creation. • Structural • Patterns that focus on the relationships between entities. • Behavioral • Patterns that focus on the communication patterns between objects. • Concurrency • Patterns that deal with multi-threaded programming techniques.

  4. What are the benefits? • Can significantly speed up the development process. • Wide adoption of common patterns result in code that is easier to understand and maintain over time. • Proper usage of design patterns will result in a better overall design.

  5. What are the drawbacks? • Can introduce more levels of indirection. • Improper usage will negate the benefits. • Adding complex design patterns to simple problems can result in over engineering.

  6. The Interface • What is it? • An interface contains only the signatures of methods, properties, events or indexers. • It is a contract between you and the rest of the world. • Why should you use it? • It insulates the rest of the world from the underlying implementation. • When should you use it? • Whenever you are needing to isolate yourself.

  7. The Interface vs. Abstract Classes • The problem setup: • A group of physicians want to have a document management system to keep track of their publications.

  8. 1 week later… • Can we have third party authored documents about us in our system?

  9. After 2 months of sheer bliss… • Can we have procedure and diagnosis information on the documents that are related to procedures they have performed?

  10. Our code is starting to cave… • There are dozens of places in our code that have logic similar to the following: publicvoidProcessDocument(Document doc) { if (doc isAuthoredDocument) { // Do author specific stuff... } if (doc isMedicalDocument) { // Do medical stuff... } if (doc is PhysicianDocument) { // Do physician stuff... } } This is dangerous!

  11. 1 day later… • Can we have patient related documents for the procedures we have done or have found on-line? ?

  12. What we could have done… if (doc isIMedicalDocument) { // Do medical stuff... } if (doc isIPhysicianDocument) { // Do physician stuff... }

  13. The Singleton • The singleton pattern is used to restrict the number of instances of a class to one. • How is this useful? • Why is this controversial?

  14. The Singleton - Implementation • Singleton C# code publicsealedclassSingleton { privatestaticreadonlySingletonm_instance = newSingleton(); ///<summary> /// Explicit static constructor to tell C# compiler /// not to mark this type as beforefieldinit ///</summary> static Singleton() { } ///<summary> /// Private constructor to enforce singleton pattern. ///</summary> private Singleton() { } ///<summary> /// Static property to return the singleton instance. ///</summary> publicstaticSingleton Instance { get { returnm_instance; } } }

  15. The Factory • The factory pattern is a creational pattern that uses a singleton object to provide implementations of a requested interface to a caller. • What are some common uses for a factory? • Logging • Configuration • Data access • Testing • What does the factory help with? • Returning Interface implementations • Simplifies complex object creation • Caching

  16. The Factory in Data Access // Retrieve our DAO from the factory. IPersonDAOdao = DAOFactory.GetInstance.GetDAO<IPersonDAO>(); // Invoke the appropriate retrieval method. • IPersonperson =dao.GetPerson(modelId);

  17. Other Factory Uses Create fake implementations instead of waiting Test really hard scenarios

  18. The Delegate • The delegate pattern is a technique where an object expresses certain behavior, but in reality delegates the responsibility for implementing/executing that behavior to an associated object. • What does the delegate help with? • Separation of concerns • Reuse of common logic • What are some common uses for a delegate? • Data access • Business layer delegates • Asynchronous programming

  19. The Delegate Inside the DAO publicIPersonGetPerson(GuidmodelId) { // Construct our delegate that can fill out our request // and empty out the response from the data source. • GetPersonDataDelegatedel = newGetPersonDataDelegate(modelId); // Obtain a reference to the call point by passing the delegate IDataCall<IPerson> call = DataCallFactory.Instance.GetDataCall(del); // Execute the call and return the result. returncall.Execute(); }

  20. A Common Problem • How should I instrument my code? • The real problems are… • What should I capture? • Where should I store the captured data? • Who should I notify when things go bad? • What does bad mean? • How do I change the system behavior to optimize the system resources that are available to me? • How do I keep my code clean???

  21. A Common Solution publicvoid Execute() { DateTimestartedOn = DateTime.UtcNow; Loggerlogger = newLogger(); try { logger.Write(string.Format( "Starting GetPerson([{0}]) at {1}", m_modelId, DateTime.UtcNow)); // Execute call logger.Write(string.Format( "Finished GetPerson([{0}]) at {1} and it worked!", m_modelId, DateTime.UtcNow)); } catch (Exception e) { logger.Write(string.Format("GetPerson([{0}]) failed {1}.", m_modelId, e)); throw; } finally { DateTimeendedOn = DateTime.UtcNow; TimingSystem.GetInstance().LogExecutionTime("GetPerson", endedOn.Subtract(startedOn)); } } What if my logger doesn’t support my needs right now? What if this was slow? Should we let someone know about this? Who was the user?

  22. A Better Solution - The Interceptor • First, design the core system without any instrumentation. • Next, identify the key points in the call stack; these are the interception points. • Finally, identify important information to communicate at the interception points.

  23. The Interceptor UML

  24. Interceptor Implementations • More can be added dynamically at run time.

  25. Using Our Interceptor • Much cleaner and more extensible publicvoid Execute() { IContextctx = Dispatcher.GetInstance().CreateContext(m_modelId); try { Dispatcher.Started(ctx); // Execute call Dispatcher.Ended(ctx); } catch (Exception e) { Dispatcher.Errored(ctx, e); throw; } }

  26. Service Oriented Architecture • What is it?

  27. Service Oriented Architecture

  28. SOA - Simplified • A simplistic view of one service What is a model? Why do you have all of these layers?

  29. Proper Coupling • Loose coupling is one of the tenants; however, appropriate sacrifices can be made to achieve performance goals. Is this allowed?

  30. Bad SOA! • You must adhere to the design pattern or your implementation will collapse under its own weight.

  31. Database Coupling

  32. Database Loose Coupling • Some data integrity checks must be moved to higher levels in the architecture. What if an account is removed?

  33. Loose Coupling Wrap-up • True loose coupling is not easy. • An event model must be part of your solution to achieve truly isolated services. • Performance and extensibility are often at odds with each other. • These design patterns are really powerful!

  34. Questions

  35. Future Topics • Unit Testing • SOA Deep Dive • Pub / Sub • Business Intelligence / Analytics • Free Text Search

More Related