Designing great frameworks training: Member Types

Continuing on the weekly series, today we posted the session on Member Types.  Thanks for watching the last week’s session on naming conventions and coming that chat… If you missed it there will be a chat transcript posted soon.  


A couple of notes on this sessions:

Slide 5: Don’t accept the defaults!  Sounds like a powerful philosophy of life as well as a good API design principle J

Slide 8: Bertrand Meyer and the Eiffel programming language

Slide 18: On properties vs. methods… If you have to error on one side or the other, error on the side of having less properties.  The exception to developers that it behaves like a field is a powerful one, not something to take lots of libraries with. 

Slide 20: I’d be interested if you have found this “bug” in your code as well.

Slide 30: More info on the Gang of Four Singleton Pattern see Design Patterns

Slide 36: Come on, who has been there?? Have you gotten a NullReferenceException from deep in the framework an assumed it is a bug in the framework? 

Side 41:So, I didn’t talk about params methods as they are somewhat uncommon.. but if you have ideas of what is wrong with this code let me know!

Slide 42: I want to stress that the Int32 vs int naming debate here is really only for public OMs… in your own code I prefer to see the language specific names “int” rather than “Int32” for example.


Member Types
Learn when to use certain member constructs such as properties, methods, and events over other constructs and why. [300k]

I will be in a chat room on 2/9 1pm PST logged in from my first leg of my FrontLine trip in Dallas Texas to answer questions and hear your comments on this topic.  The Q&A part of these classes is always my favorite part; I hope you will take time to come.
[Sign up for the chat]

Sign up for coming chats…

2/11 - Designing Inheritance Hierarchies [Sign up for the post session chat]
2/18 - API Usability [Sign up for the post session chat]
2/25 - Designing Progressive APIs [Sign up for the post session chat]


Comments (12)

  1. raul igrisan says:


    the synchronization in the singleton example you have linked to for slide 30 seems broken to me. each lazy initialization will wait on a different mutex.



  2. Here is the example that Rual is referring to (I believe)

    public sealed class DBNull {

    private DBNull() {}

    public static readonly DBNull Value = new DBNull();

    // instance Methods…


    The way this works is that the first time the DBNull class is accessed, the JIT runs the type constructor for DBNull which allocates the instance of DBNull… Each time after that the cached DBNull is returned. Notice that JIT is responsible for ensuring that only one thread causes the DBNull’s type constructor to be run.

    Does that help?

  3. raul igrisan says:

    nope. the one I’m refferin is the the Gang of 4 ‘s singleton


    // Methods

    public static LoadBalancer GetLoadBalancer()


    // Support multithreaded applications through

    // "Double checked locking" pattern which avoids

    // locking every time the method is invoked

    if( balancer == null )


    // Only one thread can obtain a mutex

    Mutex mutex = new Mutex();


    if( balancer == null )

    balancer = new LoadBalancer();



    return balancer;



    The last example you have given, the DBNull seems perfectly fine to me (thow the initialisation is not so lazy 🙂

  4. Brad Abrams on Class Members (Summary)

  5. Great information. One more better would be a WMA version for the commute. It’s also not easy enough to find this information.

  6. Neil Cowburn says:

    One request I have it is that these sessions are made as a downloadable package containing the ppt, wmv & transcript. That would be *invaluable*

  7. Thanks for the feedback Vince, Neil… I am working with the MSDN guys to see what I can do.

  8. Chad Yost says:

    Anyone know why the video is no longer showing up. I still hear it, but, since the redid the site on MSDN, there is no video. I like watching who is talking.

  9. RGab says:

    Hey Brad,

    awesome training series, was fun listening you spreading knowledge 🙂

    You are recommending using ‘static readonly’ fields instead of constants and only use constants when we are 101% sure that the literal won’t change.

    When using ‘static readonly’ though, FxCop recommends:

    Resolution : "Field ‘foo’ is declared as ‘static readonly’

    but is initialized with a constant value ‘-1’. Mark

    this field as ‘const’ instead."

    Maybe it would be cool if FxCop pointed out the caveats of using const (compiler inlining the literal, versioning problems).


Skip to main content