Why instantiate a class, all of whose methods, properties, and events are static?

[sherifffruitfly]

Hi,

I'm learning the .net Bloomberg api, and it's main class has all of its
stuff static. The help then goes on to say that the class is
implemented as a singleton. It's cool I guess to make sure not more
than one instance can be made, but with everything in the class static,
I don't actually understand why even *one* instance is required.

What's the design rationale for this?

 

[Bruce Wood]

Hi,

I'm learning the .net Bloomberg api, and it's main class has all of its
stuff static. The help then goes on to say that the class is
implemented as a singleton. It's cool I guess to make sure not more
than one instance can be made, but with everything in the class static,
I don't actually understand why even *one* instance is required.

What's the design rationale for this?

Unless they're abusing the term "singleton" to mean a static class...?

 

[sherifffruitfly]

Unless they're abusing the term "singleton" to mean a static class...?

lol! That didn't occur to me! I'm new to oop/patterns/what-not, so I
tend to use all of its terms according to strict dictionary definitions
(more or less) - such a possible "liberty" with the lingo didn't even
cross my mind...

 

[Laurent Bugnion]

Hi,

Hi,

I'm learning the .net Bloomberg api, and it's main class has all of its
stuff static. The help then goes on to say that the class is
implemented as a singleton. It's cool I guess to make sure not more
than one instance can be made, but with everything in the class static,
I don't actually understand why even *one* instance is required.

What's the design rationale for this?

If all the methods and properties in the class are static, the correct
denomination is "facade". In the facade pattern, the class acts as a
"wall" to "hide" the calls to objects. Facade classes are at the limit
between OOP and procedural programming, and should IMHO be used with
reason. To ensure that instantiation is impossible, facade classes have
a private default constructor.

A singleton class, however, ensures that maximum one instance of a class
exists at all time.

HTH,
Laurent

 

[Jon Skeet [C# MVP]]

If all the methods and properties in the class are static, the correct
denomination is "facade". In the facade pattern, the class acts as a
"wall" to "hide" the calls to objects. Facade classes are at the limit
between OOP and procedural programming, and should IMHO be used with
reason. To ensure that instantiation is impossible, facade classes have
a private default constructor.

That's not my understanding of the facade pattern. To me, the facade
pattern just presents a simpler interface, quite possibly still
involving creating an instance.

See http://en.wikipedia.org/wiki/Façade_pattern

(Unfortunately I don't have my GoF book here to check with...)

Jon

 

[Tom Porterfield]

That's not my understanding of the facade pattern. To me, the facade
pattern just presents a simpler interface, quite possibly still
involving creating an instance.

I agree with Jon. Facade pattern and whether or not methods are static are
not related. The Facade pattern is a way to create a simple interface on
top of a complex system. An example would be if you have a fairly common
operation to perform that requires some complex coordination among other
objects. You don't want to do this coordination each time you want to
perform the operation. So you can create a facade class that exposes simple
method that does the complex coordination for you. Then you just create an
instance of the facade class, call its simple method and let it worry about
what is required to actually perform the action. The method might be static
or not, that is a design decision to be made based on other criteria.

I have seen imlpementations of facade classes that take in the objects they
are going to coordinate in the constructor. This allows for reuse,
especially if designed to interfaces rather than concrete classes. But
again, the implementation will depend on the needs of the specific scenario.

 

[Laurent Bugnion, GalaSoft]

Hi,

I agree with Jon. Facade pattern and whether or not methods are static
are not related. The Facade pattern is a way to create a simple
interface on top of a complex system. An example would be if you have a
fairly common operation to perform that requires some complex
coordination among other objects. You don't want to do this
coordination each time you want to perform the operation. So you can
create a facade class that exposes simple method that does the complex
coordination for you. Then you just create an instance of the facade
class, call its simple method and let it worry about what is required to
actually perform the action. The method might be static or not, that is
a design decision to be made based on other criteria.

I have seen imlpementations of facade classes that take in the objects
they are going to coordinate in the constructor. This allows for reuse,
especially if designed to interfaces rather than concrete classes. But
again, the implementation will depend on the needs of the specific
scenario.

Interesting. I got to say, I always thought of Facades as static
classes, with the exact purpose that you state, i.e. providing a simpler
access to a complex system. I never thought of making them non-static.
Or, rather, I already made such non-static classes, but I never thought
of them as facades ;-)

Thanks for clarifying.

Laurent

 

[sherifffruitfly]

If all the methods and properties in the class are static, the correct
denomination is "facade". In the facade pattern, the class acts as a
"wall" to "hide" the calls to objects. Facade classes are at the limit
between OOP and procedural programming, and should IMHO be used with
reason. To ensure that instantiation is impossible, facade classes have
a private default constructor.

Good to know - thanks! That makes the Math class in c# make more sense
now - it's describe as a classic example of functionality that really
is procedural in nature, so they dispense with the instantiation
process by making everything static. I don't know if they made the
constructor private or not, but it sounds like they *should*.