Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Framework Design Guidelines

3,759 views

Published on

Framework Design Guidelines

Published in: Technology
  • Be the first to comment

Framework Design Guidelines

  1. 2. Communication Artifacts <ul><li>Properties </li></ul><ul><li>Methods </li></ul><ul><li>Events </li></ul><ul><li>Constructors </li></ul><ul><li>Exceptions </li></ul>
  2. 3. Four Keys of Framework Design
  3. 4. Outline
  4. 5. Naming Conventions
  5. 6. Saying It Load
  6. 7. Hungarian Notation <ul><li>Do not use Hungarian notation in publicly exposed APIs and parameter names </li></ul>public class CMyClass { int CompareTo (object objValue) {..} string lpstrName {get;} int iValue {get;} }
  7. 8. On Abbreviations, acronym, initialism and the like… <ul><li>Avoid them! </li></ul><ul><ul><li>They are a classic JLT (jargon loaded term) </li></ul></ul><ul><ul><li>OK to use them once they become words </li></ul></ul><ul><ul><ul><li>Html, Xaml, etc </li></ul></ul></ul><ul><li>Don’t just spell them out </li></ul><ul><ul><li>Use a meaningful name </li></ul></ul><ul><li>Abbreviations of more than 2 letters are cased as words, otherwise ALLUPPER </li></ul><ul><ul><li>IO vs. Html </li></ul></ul>
  8. 9. Member Design
  9. 10. Constructors are <ul><li>Do minimal work in the constructor </li></ul><ul><ul><li>Be Lazy! </li></ul></ul><ul><ul><li>Only capture the parameters </li></ul></ul>public class XmlFile { string filename; Stream data; public XmlFile(string filename) { this.data = DownloadData(filename); } } lazy
  10. 11. Properties <ul><li>Property getters should be simple and therefore unlikely to throw exceptions </li></ul><ul><li>Properties should not have dependencies on each other </li></ul><ul><ul><li>Setting one property should not affect other properties </li></ul></ul><ul><li>Properties should be settable in any order </li></ul>public class ArrayList { public int Count {get;} }
  11. 12. Properties versus Methods <ul><li>Use a Property: </li></ul><ul><ul><li>If the member logical attribute of the type </li></ul></ul><ul><li>Use a method: </li></ul><ul><ul><li>If the operation is a conversion, such as ToString() </li></ul></ul><ul><ul><li>If the getter has an observable side effect </li></ul></ul><ul><ul><li>If order of execution is important </li></ul></ul><ul><ul><li>If the method might not return immediately </li></ul></ul><ul><ul><li>If the member returns an array </li></ul></ul>
  12. 13. EmployeeList l = FillList(); for (int i = 0; i < l.Length; i++){ if (l.All[i] == x){...} } public Employee[] All {get{}} Moral: Use method if the operation is expensive Calling Code Properties and returning arrays
  13. 14. Extension Methods
  14. 15.  CONSIDER using extension methods to &quot;add&quot; methods to interfaces
  15. 16.  CONSIDER using extension methods to manage dependencies Uri uri = “ftp://some.ftp.uri”.ToUri(); // higher level assembly (not mscorlib) namespace System.Net { public static class StringExtensions{ public static Uri ToUri(this string s){ … } } }
  16. 17.  AVOID frivolously defining extension methods, especially on types you don’t own <ul><li>Might add clutter (Chaos) </li></ul><ul><li>Choose namespaces for sponsor types carefully </li></ul><ul><li>Remember that not all languages support extension methods </li></ul><ul><ul><li>Users will have to use static method call syntax </li></ul></ul>
  17. 18.  AVOID defining extension methods on System.Object
  18. 19. Type Design
  19. 20. Start Run
  20. 22. What we ship: Too much and not enough…
  21. 24. Abstract and Base classes <ul><li>Prefer broad, shallow hierarchies </li></ul><ul><ul><li>Less than or equal to 2 additional levels </li></ul></ul><ul><ul><li>Contracts and responsibilities are difficult to maintain and explain in deep complex hierarchies </li></ul></ul><ul><li>Use abstract classes </li></ul><ul><ul><li>Make it clear what the class is for </li></ul></ul><ul><ul><li>Provide a protected constructor for subclasses to call </li></ul></ul>
  22. 25. Virtual Methods <ul><li>Method call virtualizes at runtime </li></ul><ul><li>The static type doesn’t matter </li></ul><ul><li>This is the danger and power of virtual methods </li></ul><ul><ul><li>Danger : Owner of base classes cannot control what subclasses do </li></ul></ul><ul><ul><li>Power : Base class does not have to change as new subclasses are created </li></ul></ul>
  23. 26. Overriding Methods <ul><li>All Virtual members should define a contract </li></ul><ul><ul><li>Don’t change the semantics of member </li></ul></ul><ul><li>Don’t require clients to have knowledge of your overriding </li></ul><ul><li>Should you call the base? </li></ul>
  24. 27. To Virtual Or Not Virtual … <ul><li>Use non-virtual members unless you have specifically designed for specialization </li></ul><ul><ul><li>Have a concrete scenario in mind </li></ul></ul><ul><ul><li>Write the code! </li></ul></ul><ul><ul><li>Follow the Liskov Substitution Principle </li></ul></ul><ul><ul><ul><li>Must continue to call in the same order and frequency </li></ul></ul></ul><ul><ul><ul><li>Cannot increase or decrease range of inputs or output </li></ul></ul></ul><ul><ul><li>References to base types must work with derived types without knowing the difference </li></ul></ul>Barbara Liskov
  25. 28. Interfaces <ul><li>No common implementation </li></ul><ul><li>Challenging to version over releases </li></ul><ul><li>The smaller, more focused the interface the better </li></ul><ul><ul><li>1-2 members are best </li></ul></ul><ul><ul><li>But interfaces can be defined in terms of other simpler interfaces </li></ul></ul>public interface IComparable { int CompareTo(object obj); }
  26. 29.   
  27. 31. Libraries , Primitives, Abstractions
  28. 32.  CONSIDER placing library types higher on the dependency stack <ul><li>Definition: </li></ul><ul><ul><li>Library types are types that are not passed between components </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>EventLog, Debug, </li></ul></ul><ul><li>Easy to Evolve </li></ul><ul><ul><li>Leave old in, add new one </li></ul></ul><ul><ul><li>Beware of duplication! </li></ul></ul>
  29. 33.  DO keep primitives policy free (i.e. simple) <ul><li>Definition: </li></ul><ul><ul><li>Primitive types are types that are passed between components and have very restricted extensibility (i.e. no subtype can override any members) </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Int32, String, Uri. </li></ul></ul><ul><li>Hard to Evolve </li></ul><ul><li>Little need to Evolve </li></ul><ul><li>Typically in lower layers </li></ul>
  30. 34. <ul><li>Definition: </li></ul><ul><ul><li>Abstractions are interfaces or classes with unsealed members that are passed between components. </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Stream, IComponent </li></ul></ul><ul><li>Hard to Evolve </li></ul><ul><li>Unfortunately, pressure to evolve </li></ul>
  31. 35. Trends
  32. 36. Test Driven Development <ul><li>Write tests first, design later </li></ul><ul><li>Requires reusable APIs to be testable: </li></ul>
  33. 37. Heavy Dependencies & Testability
  34. 38. Inversion of Control // your better API public abstract class TraceListener { public abstract void Trace(string message); } public class Tracer { TraceListener listener; public Tracer( TraceListener listener ){ this.listener = listener; } public void Trace(string message){ listener.Trace(message); } }
  35. 39. Dependency Injection Check Containers like: Spring.NET, Castle Windsor , Structuremap, , Unity … MEF session tomorrow will talk about it (isA)
  36. 40. The Power of Sameness <ul><li>Influence of expectations </li></ul><ul><ul><li>Naming conventions and common suffixesprefixes </li></ul></ul><ul><li>Habits win out over the special cases </li></ul><ul><ul><li>Common Exception pattern </li></ul></ul><ul><li>With great power comes great responsibility </li></ul><ul><ul><li>Method overloading </li></ul></ul><ul><li>Meet developers where they are </li></ul><ul><ul><li>constructors and properties pattern teaches us to meet developers’ expectations </li></ul></ul>
  37. 41. The perilous summit of complexity by example
  38. 42. How do I read all the lines from a file?
  39. 43. VS7 Era “ IO” seems like a reasonable place to start
  40. 44. Why did they make it inaccessible Backup, and try again…
  41. 45. Open.. Looks like a good first step…
  42. 46. Hmm… OK, what do I do with a FileStream?
  43. 47. Ok good, synchronous and asynchronous operations.. What the heck is that?
  44. 48. I think I am in the wrong place..
  45. 49. Back up, let’s try a different type
  46. 50. Ahh, ReadLine(), this looks more promising..
  47. 51. OK, How do you find the end?
  48. 52. Thanks goodness there was a sample
  49. 53. The pit of success way <ul><li>developers fall into doing things the right way </li></ul>
  50. 54. Just what I need…
  51. 55. Ah, a string[] I know just what to do with that…
  52. 56. How simple!
  53. 57. Tools
  54. 58. Framework Design Tools
  55. 65. Make the simple things simple and the hard things possible
  56. 66. References <ul><li>http://blogs.msdn.com/brada (Thanks) </li></ul><ul><ul><ul><ul><li>http://channel9.msdn.com/pdc2008/PC58 </li></ul></ul></ul></ul><ul><ul><ul><ul><li>http://tinyurl.com/brad-guidelines </li></ul></ul></ul></ul><ul><li>http://blogs.msdn.com/kcwalina </li></ul><ul><ul><ul><ul><li>Krzysztof Cwalina </li></ul></ul></ul></ul><ul><li>http://tinyurl.com/msdn-guidelines </li></ul><ul><ul><ul><ul><li>Design Guidelines for Developing Class Libraries </li></ul></ul></ul></ul><ul><li>[Off-topic] </li></ul><ul><ul><li>http://tinyurl.com/patterns-enterprise </li></ul></ul><ul><ul><ul><ul><li>Patterns of Enterprise Application Architecture </li></ul></ul></ul></ul><ul><ul><ul><li>[SOLID] http://derickbailey.com </li></ul></ul></ul><ul><ul><ul><ul><li>Derick Bailey </li></ul></ul></ul></ul>

×