none
interface vs. static class (when, why?) RRS feed

  • Question

  • As first phase of freelance remote project,
    I am told to create interfaces for a framework or, rather, security API.
    The necessary actions (and thereafter methods) are already specified

    The requirements are very similar to System.Web.Security API:
    to get, to put, to validate the users, the groups, the roles from/to a database, AD
    but for Windows Forms

    I browsed System.Web.Security and there are no interfaces

    There are, for ex.:
    public static class Membership
    public abstract class MembershipProvider : ProviderBase
    public abstract class ProviderBase

    Can you advise me the texts on best practices for framework, API design?

    In the case of Security API, why there are no interfaces?
    When to use interface vs. "static class"? What are arguments?

    Can I consider the service class (like Membership) to be the "interface" for my task?

    What are implications of using interfaces instead of service class, or vice versa?
    Sunday, November 25, 2007 6:41 AM

Answers



  • for a book, try the "Framework Design Guidelines", by Krysztof Cwalina and Brad Abrams, it's a Microsoft Press Book.

    An abstract class would be used to derive some functionality, which an interface could not provide.  You could put an interface on that if you wanted, but I suspect the base class is being used in lieu of an interface.

    the provider classes that a developer creates them inherit certain aspects of the base, whilst providing their own specific functionality, which then using the provider pattern will be loaded and used as required.

    In terms of using a static class versus an interface, a static class would be used as a helper, i.e. it would be a single instance of the class, whereas a class being instantiated through an interface may have many different implementations, and is generally used for multiple instance classes.  You use a static class when you just want a class to do something, and not store state information particular to that call.  An interface would be used more for general OO programming.

    I'd say that providerbase is more like an interface in the way it is used.  The membership class is going to be a container class for things that you can do that are to do with the membership functional area.

    I don't know if that helps you,

    Martin Platt.
    Thursday, November 29, 2007 11:54 PM

All replies



  • for a book, try the "Framework Design Guidelines", by Krysztof Cwalina and Brad Abrams, it's a Microsoft Press Book.

    An abstract class would be used to derive some functionality, which an interface could not provide.  You could put an interface on that if you wanted, but I suspect the base class is being used in lieu of an interface.

    the provider classes that a developer creates them inherit certain aspects of the base, whilst providing their own specific functionality, which then using the provider pattern will be loaded and used as required.

    In terms of using a static class versus an interface, a static class would be used as a helper, i.e. it would be a single instance of the class, whereas a class being instantiated through an interface may have many different implementations, and is generally used for multiple instance classes.  You use a static class when you just want a class to do something, and not store state information particular to that call.  An interface would be used more for general OO programming.

    I'd say that providerbase is more like an interface in the way it is used.  The membership class is going to be a container class for things that you can do that are to do with the membership functional area.

    I don't know if that helps you,

    Martin Platt.
    Thursday, November 29, 2007 11:54 PM
  •  Martin Platt wrote:
    for a book, try the "Framework Design Guidelines", by Krysztof Cwalina and Brad Abrams, it's a Microsoft Press Book.

    huh, for 3 days I could not manage to post untill I followed all procedures from
    http://forums.microsoft.com/MSDN/languages/en-US/docs/faq.aspx?SiteID=1#4

    Martin, thanks for your response,
    I certainly searched for all combinations of keywords from the title "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" but could not find it.


    The question was rather not about what they are or what are the differences but what are the principles or best practices, well, guidelines to use one vs. the other. So far, I do not need to use (implement, instantiate or call methods
    I cannot tell that what u have sadi helped me to design or use them
    BTW I doubt that static class has even a single instance.

    Meanwhile,
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2455974&SiteID=1
    I found to be extremely useful the book
    Juval Lowy .
    Programming .NET Components, 2nd Edition. Publisher:
    O'Reilly. Pub Date: July 2005.
    ISBN: 0-596-10207-0

    http://safari.oreilly.com/0596102070

    It is very easy and interesting to read and  practically helpful

    There are many good guidelines and realy very useful practically code examples (or rather applications).
    For ex., to have no more than 2-4 methods declarations per interface

    Guennadi Vanine -- Gennady Vanin -- Геннадий Ванин

    Saturday, December 1, 2007 9:40 AM
  •  

    The Framework book mentioned is a must read because it explains the problems the .net team had with interfaces and why they moved to using base classes instead. Essentially the basic idea is that you can more easily add to a base class without forcing a change on the clients. Obviously there are pro's and con's but their experience makes for an interesting read, there is a web cast (about 2 hrs) where they talk about it too.
    Saturday, December 1, 2007 4:42 PM