VB6 v. C# (something is missing!)

[Ole Olsen]

I originally come from a VB6 background, now entirely programming in C#.
All in all a great language (C#) with a lot of powerful entities; there is however one thing that I just can't seem to figure out.

In VB6, when creating a Class, you can mark it at "PublicNotCreatable", meaning that it is not possible to instantiate it directly. This would one normally do, it you want to force people to access this concrete class through a defined Interface.

So you would write something like this in the Client app.

Dim myobject as IInterface
Set myobject = new myClass 'this is OK

if trying this approach:
Dim myobject as myClass
Set myobject = new myClass ' this wil FAIL

I think this is a quite nice feature, that you can force people to access your class via an Interface. Now - how do I accomplish this "shielding"/forcing in C#.NET?????

/Thanks!
/Ole

 

[David]

I don't quite see the benefits of this?? Can you explain?

David.
I originally come from a VB6 background, now entirely programming in C#.
All in all a great language (C#) with a lot of powerful entities; there is however one thing that I just can't seem to figure out.

In VB6, when creating a Class, you can mark it at "PublicNotCreatable", meaning that it is not possible to instantiate it directly. This would one normally do, it you want to force people to access this concrete class through a defined Interface.

So you would write something like this in the Client app.

Dim myobject as IInterface
Set myobject = new myClass 'this is OK

if trying this approach:
Dim myobject as myClass
Set myobject = new myClass ' this wil FAIL

I think this is a quite nice feature, that you can force people to access your class via an Interface. Now - how do I accomplish this "shielding"/forcing in C#.NET?????

/Thanks!
/Ole

 

[Ole Olsen]

Well - lets imagine that the concrete class contained more properties and methods than was defined in the Interface.

By being allowed to instantiate the Class directly - these extra method/properties are visible. If declaring your object as an Interface - only the defined properties/methods are exposed (as disired!).

Reason enough?

Thanks!
/Ole


I don't quite see the benefits of this?? Can you explain?

David.
I originally come from a VB6 background, now entirely programming in C#.
All in all a great language (C#) with a lot of powerful entities; there is however one thing that I just can't seem to figure out.

In VB6, when creating a Class, you can mark it at "PublicNotCreatable", meaning that it is not possible to instantiate it directly. This would one normally do, it you want to force people to access this concrete class through a defined Interface.

So you would write something like this in the Client app.

Dim myobject as IInterface
Set myobject = new myClass 'this is OK

if trying this approach:
Dim myobject as myClass
Set myobject = new myClass ' this wil FAIL

I think this is a quite nice feature, that you can force people to access your class via an Interface. Now - how do I accomplish this "shielding"/forcing in C#.NET?????

/Thanks!
/Ole

 

[Bjorn Abelli]

...

In VB6, when creating a Class, you can mark it at
"PublicNotCreatable", meaning that it is not possible to
instantiate it directly. This would one normally do, it
you want to force people to access this concrete class
through a defined Interface.

So you would write something like this in the Client app.

Dim myobject as IInterface
Set myobject = new myClass 'this is OK

if trying this approach:
Dim myobject as myClass
Set myobject = new myClass ' this wil FAIL

I must admit I haven't seen anything like that in VB before, but then again
I didn't do so much VB programming either...

I think this is a quite nice feature, that you can
force people to access your class via an Interface.
Now - how do I accomplish this "shielding"/forcing in
C#.NET?????

I think I understand where you're going. However, even if you could
accomplish that, what would be the actual benefit of doing that?

As the class has implemented the interface, all of the behaviour expected
from the interface is available through the instance even if the variable is
of the class type.

If the class has implemented the interface, the instance still is-an
"instance of the interface".

Perhaps the following approach at least comes "near" what I think you're
searching for:

public interface MyInterface { }

public class MyClass : MyInterface
{
private MyClass()
{
// Any needed initiation...
}

public static MyInterface FactoryMethod()
{
MyInterface mif = new MyClass();
return mif;
}
}

Which in turn can be used in a "similar" manner as what you had in VB:

MyInterface x = MyClass.FactoryMethod(); // Allowed

MyInterface x = new MyClass(); // Not compilable
MyClass x = new MyClass(); // Not compilable
MyClass x = MyClass.FactoryMethod(); // Not compilable

I'm not sure it covers all bases of what the OP wants as it in C# still can
be "cast" to a variable in either direction (variable of the interface
type --> variable of the class type, and vv.).

// Bjorn A

 

[Bjorn Abelli]

...

Well - lets imagine that the concrete class contained more
properties and methods than was defined in the Interface.

By being allowed to instantiate the Class directly - these
extra method/properties are visible. If declaring your object
as an Interface - only the defined properties/methods are
exposed (as disired!).

Reason enough?

No.

If you don't want those extra method/properties in the class to be visible,
just declare them private.


// Bjorn A

 

[Ole Olsen]

No, you are right!
I am beginning to see a pattern form here - we are to use "Static
Constructors" to accomplish this type of behaviour?

Well - thanks for the response, all

/Ole

 

[Ole Olsen]

I would potentially like these precise poroperties/methods to be used in
other context (ie. another interface also implemented by this class. Okay -
we are far out now, but in theory?

Thanks!
/Ole

 

[Frank Oquendo]

I would potentially like these precise poroperties/methods to be used
in other context (ie. another interface also implemented by this
class. Okay - we are far out now, but in theory?

You need to look at this from a different angle. What you want is a class
factory that will return an object implementing the chosen interface.
Without using such a pattern, anyone who instantiates your class will have
access to all the public methods of that class. This is not unique to C#.

 

[Ole Olsen]

I think you are right! I might need to look at things in a different
perspective.

Just too bad that I have to create a Factory (Factory Pattern) for this,
which was just a single property in VB6?

Well - it seems I have finally managed to identify something that was easier
in VB6.

Thanks all!
/Ole

 

[Uri Dor]

class kuku
{
private kuku(whatever) {do something}
static get_a_fresh_kuku(params) { return new kuku(whatever); }
}

does that answer your question, or did I misunderstand your post?

 

[Bjorn Abelli]

I would potentially like these precise properties/methods
to be used in other context (ie. another interface also
implemented by this class. Okay - we are far out now, but
in theory?

If I understand you correct, you're actually trying to "subtype to the
interfaces" in order to "narrow" the possible behaviour of the actual class.

That's not a common OO-approach (it breaks the Liskov substitutable
principle), though I've seen similar things in the past, but I can't
remember a single one that did it with success.

Maybe you just should consider a different design, where you actually create
two different classes, one for each context.

// Bjorn A

 

[Andreas Håkansson]

Ole,

Yes you create the class so it dot NOT have any public contrustors
and then you use a static method to create the object. Static methods are
methods which can be called directly on the class and does not require an
class object.

You could also use internal contructors (check the internal keyword) which
makes the contructors public INSIDE your project, but privete OUTSIDE
your project.

HTH,

//Andreas

 

[Frank Oquendo]

Well - it seems I have finally managed to identify something that was
easier in VB6.

If you want a class that is PublicNotCreatable, you simply specify private
or internal for the class constructor. This is no different than it was in
VB.

In fact, neither is the creation of the object. If a client can use a VB
object but not create it, you have to write a public method that will
instantiate the object and pass it back to the client.

 

[Uri Dor]

Just one terminology issue - get_a_fresh_kuku(params) isn't a static
constructor, it's a static method that returns an instance. A static
constructor initializes static class members.