The IFooStream just connects both types since both got a length and a
position,... But actually the IByteStream and the IFloatStream already
exist as an essential part of the audio lib.
Suona come gli unici altri tipi nella lib che dipendono da IFooStream
e IReadableFooStream<T>
sono IByteStream
e IFloatStream
. Questi ultimi due sembrano quelli interessanti che usano il resto della lib. Se nessun altro tipo effettivamente dipende da IReadableFooStream<T>
, ed è lì per motivi di ereditarietà, sono d'accordo che odori.
I really need them to know whether an implementation provides raw data
or provides samples.
Quindi, perché non preferire la composizione sull'ereditarietà e chiamarli come sono?
public interface IProvideRawStream
{
IFooStream Stream { get; }
int Read(byte[] buffer, int offset, int count);
}
public interface IProvideSampleStream
{
IFooStream Stream { get; }
int Read(float[] buffer, int offset, int count);
}
... o, se la composizione non ha senso nell'API, cosa c'è di sbagliato nell'avere ereditarietà di un solo livello?
public interface IFooStream
{
long Length { get; }
long Position {get; set;}
//...
}
public interface IProvideRawStream : IFooStream
{
int Read(byte[] buffer, int offset, int count);
}
public interface IProvideSampleStream : IFooStream
{
int Read(float[] buffer, int offset, int count);
}