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 "PublicNotCreat able", 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]

Re: VB6 v. C# (something is missing!)

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

David.
"Ole Olsen" <Ole@olsen.it > wrote in message news:%23ZK5w0UJ EHA.3712@TK2MSF TNGP09.phx.gbl. ..
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 "PublicNotCreat able", 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]

Re: VB6 v. C# (something is missing!)

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


"David" <not@vailable.c om> wrote in message news:OI2bV$UJEH A.4052@TK2MSFTN GP11.phx.gbl...
I don't quite see the benefits of this?? Can you explain?

David.
"Ole Olsen" <Ole@olsen.it > wrote in message news:%23ZK5w0UJ EHA.3712@TK2MSF TNGP09.phx.gbl. ..
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 "PublicNotCreat able", 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]

Re: VB6 v. C# (something is missing!)

"Ole Olsen" wrote...
[color=blue]
> In VB6, when creating a Class, you can mark it at
> "PublicNotCreat able", 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[/color]

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...
[color=blue]
> 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?????[/color]

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.Factory Method(); // Allowed

MyInterface x = new MyClass(); // Not compilable
MyClass x = new MyClass(); // Not compilable
MyClass x = MyClass.Factory Method(); // 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

[Uri Dor]

Re: VB6 v. C# (something is missing!)

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

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

Ole Olsen wrote:[color=blue]
> 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 "PublicNotCreat able",
> 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[/color]

[Bjorn Abelli]

Re: VB6 v. C# (something is missing!)

"Ole Olsen" wrote ...
[color=blue]
> 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?[/color]

No.

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


// Bjorn A

[Ole Olsen]

Re: VB6 v. C# (something is missing!)

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


"Uri Dor" <replace_yu_ar_ eye@mivzak.com> wrote in message
news:eMgNaXVJEH A.3628@TK2MSFTN GP12.phx.gbl...[color=blue]
> class kuku
> {
> private kuku(whatever) {do something}
> static get_a_fresh_kuk u(params) { return new kuku(whatever); }
> }
>
> does that answer your question, or did I misunderstand your post?
>
> Ole Olsen wrote:[color=green]
> > 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 "PublicNotCreat able",
> > 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[/color][/color]

[Ole Olsen]

Re: VB6 v. C# (something is missing!)

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


"Bjorn Abelli" <bjorn_abelli@D oNotSpam.hotmai l.com> wrote in message
news:eFoaedVJEH A.644@tk2msftng p13.phx.gbl...[color=blue]
> "Ole Olsen" wrote ...
>[color=green]
> > 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?[/color]
>
> No.
>
> If you don't want those extra method/properties in the class to be[/color]
visible,[color=blue]
> just declare them private.
>
>
> // Bjorn A
>
>
>[/color]

[Frank Oquendo]

Re: VB6 v. C# (something is missing!)

Ole Olsen wrote:[color=blue]
> 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?[/color]

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#.

--
Gravity: it's not just a good idea, it's the law.

[Ole Olsen]

Re: VB6 v. C# (something is missing!)

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


"Frank Oquendo" <no.email@here. com> wrote in message
news:ehVg3kVJEH A.1340@TK2MSFTN GP12.phx.gbl...[color=blue]
> Ole Olsen wrote:[color=green]
> > 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?[/color]
>
> 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#.
>
> --
> Gravity: it's not just a good idea, it's the law.
>
>[/color]

[Bjorn Abelli]

Re: VB6 v. C# (something is missing!)


"Ole Olsen" wrote...[color=blue]
>
> 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?[/color]

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]

Re: VB6 v. C# (something is missing!)

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

"Ole Olsen" <Ole@olsen.it > skrev i meddelandet
news:uc%23QRfVJ EHA.1764@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> 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
>
>
> "Uri Dor" <replace_yu_ar_ eye@mivzak.com> wrote in message
> news:eMgNaXVJEH A.3628@TK2MSFTN GP12.phx.gbl...[color=green]
> > class kuku
> > {
> > private kuku(whatever) {do something}
> > static get_a_fresh_kuk u(params) { return new kuku(whatever); }
> > }
> >
> > does that answer your question, or did I misunderstand your post?
> >
> > Ole Olsen wrote:[color=darkred]
> > > I originally come from a VB6 background, now entirely programming in[/color][/color][/color]
C#.[color=blue][color=green][color=darkred]
> > > All in all a great language (C#) with a lot of powerful entities;[/color][/color][/color]
there[color=blue][color=green][color=darkred]
> > > is however one thing that I just can't seem to figure out.
> > >
> > > In VB6, when creating a Class, you can mark it at[/color][/color][/color]
"PublicNotCreat able",[color=blue][color=green][color=darkred]
> > > 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[/color][/color]
>
>[/color]

[Frank Oquendo]

Re: VB6 v. C# (something is missing!)

Ole Olsen wrote:
[color=blue]
> Well - it seems I have finally managed to identify something that was
> easier in VB6.[/color]

If you want a class that is PublicNotCreata ble, 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.

--
Gravity: it's not just a good idea, it's the law.

[Uri Dor]

Re: VB6 v. C# (something is missing!)

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

Ole Olsen wrote:
[color=blue]
> 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
>
>
> "Uri Dor" <replace_yu_ar_ eye@mivzak.com> wrote in message
> news:eMgNaXVJEH A.3628@TK2MSFTN GP12.phx.gbl...
>[color=green]
>>class kuku
>>{
>>private kuku(whatever) {do something}
>>static get_a_fresh_kuk u(params) { return new kuku(whatever); }
>>}
>>
>>does that answer your question, or did I misunderstand your post?
>>
>>Ole Olsen wrote:
>>[color=darkred]
>>>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 "PublicNotCreat able",
>>>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[/color][/color]
>
>
>[/color]