Re: Java/OO techniques for modularity and re-use
Richard Maher wrote:
Since SSLSocket inherits from Socket then you can make your
t3sock of type Socket (you can assign from a subtype to a
super type).
But because SSLSocket "extends" Socket, surely I have to instantiate a
SSLSocket object somewhere don't I?
Really no need for this: -
sockFactory = (SSLSocketFactory)SSLSocketFactory.getDefault();
t3Sock = (SSLSocket)sockFactory.createSocket();
That works fine if t3Sock is declared to have type Socket.
And since all methods are virtual in Java, then if t2Sock is
a SSLSocket, then that class's methods will be used.
What about all the Value-Added SSL bits that the SSLSocket class must
bolt-on to a Socket?
If you need to use a SSL specific funtion you can use:
((SSLSocket)t3Sock).someSSLSOcketSpecificMethod()
You're casting t3Sock (a Socket object) as a SSLSocket object there right? I
haven't missed some abstract-class or Interface wizardry? So I've got a
vanilla Socket and cast it as a SSLSocket to call, say startHandshake(), and
it's not gonna complain about a bodgy brick-veneer job, absent any
certificate or crypto-algorithm info?
t3Sock is declared as a Socket, but it it actually is a SSLSocket, then
it can be cast to a SSLSocket and therefore use the SSLSocket
specific methods.
I'd find it easier to picture it the other way around where we have a
SSLSocket and our casting it as a Socket effectively masks out all the SSL
bits, but who cares?
You can not assign a Socket to a SSLSocket, so it has to be this way
around.
But that is not "nice".
It's certainly more appealing than the attached code (look for "sslReqd")
True.
Arne