You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a data provider which needs some customization on the network stream (it requires to be decompressed).
Currently, the class SocketInitiatorThread has a method protected virtual SetupStream() with the comment:
/// <summary>
/// Setup/Connect to the other party.
/// Override this in order to setup other types of streams with other settings
/// </summary>
/// <returns>Stream representing the (network)connection to the other party</returns>
So this is clearly the place I should override and add the customization.
My problem is that this class is created on SocketInitiator.DoConnect, with this implementation:
protected override void DoConnect(SessionID sessionID, Dictionary settings)
{
Session session = null;
try
{
session = Session.LookupSession(sessionID);
if (!session.IsSessionTime)
return;
IPEndPoint socketEndPoint = GetNextSocketEndPoint(sessionID, settings);
SetPending(sessionID);
session.Log.OnEvent("Connecting to " + socketEndPoint.Address + " on port " + socketEndPoint.Port);
//Setup socket settings based on current section
var socketSettings = socketSettings_.Clone();
socketSettings.Configure(settings);
// Create a Ssl-SocketInitiatorThread if a certificate is given
SocketInitiatorThread t = new SocketInitiatorThread(this, session, socketEndPoint, socketSettings);
t.Start();
AddThread(t);
}
catch (System.Exception e)
{
if (null != session)
session.Log.OnEvent(e.Message);
}
}
So, in order to inherit from SocketInitiatorThread, and override SetupStream, I have to also inherit from SocketInitiator and override DoConnect.
Unfortunatly, many methods used inside DoConnect are private (like GetNextSocketEndPoint, AddThread, etc.). And I´ll end up having to duplicate the whole class.
I propose either: (1) Extract the line which creates the SocketInitiatorThread to a virtual method
public virtual CreateSocketInitiatorThread(Session session, IPEndPoint socketEndPoint, SocketSettings socketSettings)
{
return new SocketInitiatorThread(this, session, socketEndPoint, socketSettings);
}
or (2) Inject a factory (ISocketInitiatorThreadFactory) into SocketInitiator, such that:
public interface ISocketInitiatorThreadFactory
{
SocketInitiatorThread Create(Transport.SocketInitiator initiator, Session session, IPEndPoint socketEndPoint, SocketSettings socketSettings);
}
class DefaultSocketInitiatorThreadFactory : ISocketInitiatorThreadFactory
{
public SocketInitiatorThread Create(SocketInitiator initiator, Session session, IPEndPoint socketEndPoint, SocketSettings socketSettings)
=> new SocketInitiatorThread(initiator, session, socketEndPoint, socketSettings);
}
And then create a new constructor receiving the factory. (the other constructors will use the default factory).
I much rather the second approach since the 1st one can lead to violating LSP
The text was updated successfully, but these errors were encountered:
I have a data provider which needs some customization on the network stream (it requires to be decompressed).
Currently, the class
SocketInitiatorThread
has a methodprotected virtual SetupStream()
with the comment:So this is clearly the place I should override and add the customization.
My problem is that this class is created on
SocketInitiator.DoConnect
, with this implementation:So, in order to inherit from
SocketInitiatorThread
, and overrideSetupStream
, I have to also inherit fromSocketInitiator
and overrideDoConnect
.Unfortunatly, many methods used inside
DoConnect
are private (likeGetNextSocketEndPoint
,AddThread
, etc.). And I´ll end up having to duplicate the whole class.I propose either:
(1) Extract the line which creates the
SocketInitiatorThread
to a virtual methodor
(2) Inject a factory (
ISocketInitiatorThreadFactory
) intoSocketInitiator
, such that:And then create a new constructor receiving the factory. (the other constructors will use the default factory).
I much rather the second approach since the 1st one can lead to violating LSP
The text was updated successfully, but these errors were encountered: