Re: Static Classes ... in response to B. Voigt's comments

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Mon, 24 Mar 2008 21:16:47 -0700, Bill Woodruff <billw@xxxxxxxxxxxxxx> wrote:

Some good points there to think on, Peter. Appreciated. One thought that
occurs to me is to wonder (I guess I'll have to go back to the "epiphany" as
revealed by the Gang of Four to check on it) if the "original" concept of a
Singleton had any reference to Interfaces or Inheritance. But that could
just turn out to be a pedantic quest. Me like Interfaces, Rhino or no Rhino.

I can't speak for what the GoF book says (haven't read it...I have to admit, though it's not specifically why I haven't read the book, I'm a bit put off by the whole "Gang of Four" moniker...what's up with that?), but Wikipedia's entry seems to me to not only call out a singleton as specifically an instanced object, but it even discusses the difference between a singleton and a static class.
http://en.wikipedia.org/wiki/Singleton_pattern

The thought also comes that most of us writing WinForms applications make
use of a Static class, Program.cs, every time we use the default WinForms
app template to start a new project :)

Sort of. I mean, the Program class is static by default, but there's no real requirement that it be so. If you thought there was some value in making it an instantiable class, you could, singleton or otherwise. In fact, the console application template doesn't make it static.

Of course that's not a Singleton
since you can run multiple copies of the .exe. I've seen a variety of ways
to make sure one-and-only-one instance of your app runs.

I think the two are not really the same thing. But at the same time, I'm perfectly comfortable saying that you could have a singleton Program class, or a singleton application, or both, or neither.

I'd admit the term doesn't seem directly applicable according to the Wikipedia description of a singleton (it seems to imply that a singleton _must_ be a class in an object oriented language). But it seems to me that one value of the idea of design patterns is that they are general enough to be applicable in a variety of settings, as long as the objects being described behave in a certain way and can be controlled in a certain way.

A Windows process isn't normally managed the way a singleton is (i.e. with some global entity that manages instantiation and caching of an instance), but it _could_ be, and even in the more common case of a process checking for itself already existing, I think it's a reasonable expansion of the idea to call it a singleton application in that case.

So maybe I should be careful to distinguish between Singleton as a pattern
that enforces one-and-one-only of some object, and "Singleton" as a method
of having a single-instance-at-a-time-running in the context of WinForms
apps ?

Depends on who you're talking to. I don't think you need to be. :)

Interfaces, as contracts that enforce, appeal to me but I keep sometimes
wondering why there isn't an Interface "flavour" that specifies the scoping
of what it requires you code : i.e., that says, in effect : "when you
inherit from this Interface, you must implement this as static, this as
public, and this as private readonly." From an "enforcement" point of view
I like that, but realize it's really not what Interfaces as we have them now
are.

Right, it's not. Interfaces describe the public API that a class instance exposes. It's a way of passing an object around without caring what the object really is, but rather just caring about what it can do.

In that context:

-- static interfaces don't make sense because you can't pass around a static class
-- private interface members don't make sense because that defines an implementation detail, not a public API

I don't think a contract requiring a private member would ever make sense. After all, no one would ever see the private member except the class implementing it. A protected member makes more sense, but that's actually possible via abstract classes. You can only inherit one abstract class in C#, but then you'd only ever be able to see one implementation of a protected member in C# either (for the same reason).

In other words, while I think I understand where the original thought you've expressed comes from, I also think that the system would become inconsistent if interfaces supported those kinds of things.

Pete
.

Relevant Pages

  • Re: singleton vs static
    ... > Advantages of Singleton: ... GoF's Design Patterns book says itself that it's not an OO primer, ... during which these interfaces are sucked back out ... It's often appropriate to design a Facade interface as the only way to ...
    (comp.object)
  • Re: Static Classes ... in response to B. Voigts comments
    ... Peter Duniho wrote: "... ... me that one obvious difference between a static class and the singleton ... Singleton had any reference to Interfaces or Inheritance. ... use of a Static class, Program.cs, every time we use the default WinForms ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Can use of singletons denote poor project design?
    ... Daniel Parker wrote: ... Program State: Again a central point to keep track of program status. ... "It is a truth universally acknowledged, that a singleton in possession ... Model, View, and Controller interfaces. ...
    (comp.object)
  • Re: Really want to understand Singleton, and maybe static classes
    ... If the application has a Singleton class with a structure as ... public sealed class ProjectStore ... application domain (AppDomain). ... Apart from more typing for the field member, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Z.Irregular Set Theory. A correction.
    ... And this single member is a member of all sets, or rather, the set containing this member is a member of all sets? ... If there are more than one basic element, then there are more than one singleton set, since each element can alone constitute a set. ... N will be the set of all ordinals. ... This theory has a universe as I demonstrated above, while ZFC doesn't ...
    (sci.math)