Instancing a class where base object already exists

[Lee Gillie]

What I am hoping to do is make a constructor for a derived class that
can accept an instance of the base class. Maybe this just is not possible?

I am working with the new SSLStream in the 2005 beta. They came up with
what seems to be an awkward object model to me. The SSLStream has nearly
the same member signature as a NetworkStream. Both are derived from
Stream. But in both cases you need a TCPClient instance to get them
going. This leaves you constantly checking to see if the socket has been
negotiated for SSL, and if it has you must do I/O on the SSLStream and
if not on the "Client" property of the TCPClient.

Other implementors have chosen to give you a single socket type object
that can be used for either clear text or SSL encrypted communications.
This is MUCH handier. For .NET I sure wish they would have made
TCPClient upgradable, and as such the Client property would give you an
upgraded NetworkStream. I am creating software that has to be able to
upgrade and downgrade the socket on the fly.

My thought was to derive a class from TCPClient with a property called
"NetStream" that would either return the client property of TCPClient if
SSL has not yet been negotiated, or the SSLStream object if it has, but
in both cases cast as a Stream. The complication is that when listening
for connections the framework instances the TCPClient for you in your
call to Accept, so you already have the instance for the base for this
new derived class. What would be cool is if there were a way to make an
overloaded constructor in my derived class that would accept the
instance of the base class.

I know there are some new object capabilities in 2005, but haven't found
a way to do this.

Can you teach an old dog a new trick?

 

[Tom Shelton]

What I am hoping to do is make a constructor for a derived class that
can accept an instance of the base class. Maybe this just is not possible?

I am working with the new SSLStream in the 2005 beta. They came up with
what seems to be an awkward object model to me. The SSLStream has nearly
the same member signature as a NetworkStream. Both are derived from
Stream. But in both cases you need a TCPClient instance to get them
going. This leaves you constantly checking to see if the socket has been
negotiated for SSL, and if it has you must do I/O on the SSLStream and
if not on the "Client" property of the TCPClient.

Other implementors have chosen to give you a single socket type object
that can be used for either clear text or SSL encrypted communications.
This is MUCH handier. For .NET I sure wish they would have made
TCPClient upgradable, and as such the Client property would give you an
upgraded NetworkStream. I am creating software that has to be able to
upgrade and downgrade the socket on the fly.

My thought was to derive a class from TCPClient with a property called
"NetStream" that would either return the client property of TCPClient if
SSL has not yet been negotiated, or the SSLStream object if it has, but
in both cases cast as a Stream. The complication is that when listening
for connections the framework instances the TCPClient for you in your
call to Accept, so you already have the instance for the base for this
new derived class. What would be cool is if there were a way to make an
overloaded constructor in my derived class that would accept the
instance of the base class.

I know there are some new object capabilities in 2005, but haven't found
a way to do this.

Can you teach an old dog a new trick?

Public Class MyDerivedClass
Inherits TCPClient

Private instance As TCPClient

' insert other constructors here

Public Sub New (ByVal tcpInstance As TCPClient)
Me.instance = tcpInstance

' more cool stuff...
End Sub

End Class


Does this help?

 

[Lee Gillie]

Public Class MyDerivedClass
Inherits TCPClient

Private instance As TCPClient

' insert other constructors here

Public Sub New (ByVal tcpInstance As TCPClient)
Me.instance = tcpInstance

' more cool stuff...
End Sub

End Class


Does this help?

Ummmm, well... the way I understand it, with your suggestion there are
now TWO instances of TCPClient. One in the base of any instance of
MyDerivedClass. Plus also the private member called "instance".

I guess I hear you saying to overload every possible method of TCPClient
so that I may redirect the calls to instance.methodxxx? I can see that
working.

But if I could really set the instance of the base of MyDerivedClass,
then there would only be one instance of TCPClient. Even if there were
momentarily two instances of TCPClient... the much bigger issue for me,
would be that it would not be necessary to override all public members
of TCPClient.

If I could set the instance of the base of MyDerivedClass, then when
TCPClient changes, gets new members, they are automatically revealed via
the MyDerivedClass interface. I create a new maintenance issue for
myself otherwise.

I don't see what kind of canons of OOP would be violated by allow this.

- Lee

 

[alantolan]

Why inherit from TCPClient if we are going to encapsulate as well?

By inheriting, MyDerivedClass offers all the TCPClient interface to the
user but when called they will act on the 'base TCPClient' instead of
the encapsulated instance.

Unless we are planning to shadow all of the TCPClient interface in the
MyDerivedClass and create new versions acting upon instance

e..g

public shadows Function GetStream() as
System.Net.Sockets.NetworkStream
return instance.GetStream()
end function

then I don't see how 'instance' will ever get used.

What am I missing?


I am rather limited in my comments as I don't have '05 and can't try
out the SSLStream but a possible solution (though not inheriting from
TcpClient - so it cannot be used polymorphically with client, which may
be an issue) is...

imports System.Net
imports System.Net.Sockets

' Implements secure and non-secure stream
Class MyChannel

private _client as TcpClient
private _stream as NetworkStream

' ctors can be implemented in multiple ways - pass in a tcpclient or
pass in the items needed to instantiate the tcpclient. For ease of
coding, just pass in tcpclient

public sub new ( client as TcpClient)
_client = client
_stream = client.GetStream()
end sub

' secure the stream. No idea what needs to be passed in - really
should get '05 at some point.
Public sub SecureStream( <whatever params are needed to set up the
secure stream> )

_stream = new SSLStream(_stream, <whatever params>)

end sub

' returns the standard ClientStream is not secure or else the
SSLStream
Public readonly property Stream() as NetworkStream
Get
_return _stream
End Get
End Property

End class


hth,
Alan.

 

[Lee Gillie]

Why inherit from TCPClient if we are going to encapsulate as well?

By inheriting, MyDerivedClass offers all the TCPClient interface to the
user but when called they will act on the 'base TCPClient' instead of
the encapsulated instance.

Unless we are planning to shadow all of the TCPClient interface in the
MyDerivedClass and create new versions acting upon instance

e..g

public shadows Function GetStream() as
System.Net.Sockets.NetworkStream
return instance.GetStream()
end function

then I don't see how 'instance' will ever get used.

What am I missing?


I am rather limited in my comments as I don't have '05 and can't try
out the SSLStream but a possible solution (though not inheriting from
TcpClient - so it cannot be used polymorphically with client, which may
be an issue) is...

imports System.Net
imports System.Net.Sockets

' Implements secure and non-secure stream
Class MyChannel

private _client as TcpClient
private _stream as NetworkStream

' ctors can be implemented in multiple ways - pass in a tcpclient or
pass in the items needed to instantiate the tcpclient. For ease of
coding, just pass in tcpclient

public sub new ( client as TcpClient)
_client = client
_stream = client.GetStream()
end sub

' secure the stream. No idea what needs to be passed in - really
should get '05 at some point.
Public sub SecureStream( <whatever params are needed to set up the
secure stream> )

_stream = new SSLStream(_stream, <whatever params>)

end sub

' returns the standard ClientStream is not secure or else the
SSLStream
Public readonly property Stream() as NetworkStream
Get
_return _stream
End Get
End Property

End class


hth,
Alan.

This works. Or nearly. The only common base of NetworkStream and
SSLStream is Stream, a base of both NetworkStream and SSLStream. So
_stream would be a "Stream". Where CommandChannel is an instance of your
MyChannel then one would do I/O with it in a singular way, regardless of
whether the stream is SSL or not...

CommandChannel.Stream.BeginRead( ...

Had we been able to discover a way to set the base class instance, with
inheritance, this would instead be something like:

CommandChannel.BeginRead( ...

But at least your way we could avoid this scenario:

If mSecured Then
SSLChannel.BeginRead(...
Else
TCPClient.GetStream.BeginRead(...
End If

Of course the main point is to be able to program the I/O handling blind
to the fact that SSL is engaged or not. What you propose, instead of
inheritance, accomplishes that.

In any case, can you see how truly handy it would be if there were an
OOP primitive to construct a derived class with the base class instance
already existing, and to be able to specify it to the constructor? I
think to answer my original question then, we would have to say there IS
NO WAY OF DOING IT. But there are other effective approaches to making
the I/O model blind to being secure.

Thanks for all the input.
Best regards - Lee