"Il y a peu de choses qui me soient impossibles..."
Campbell Ritchie wrote:If you have a superclass which completely implements both those methods, and a subclass which ignores one method, can you legitimately say that subclass object “IS‑A” superclass object?
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:...my purpose is never to pass an In reference to anything that needs any Out methods
Stevens Miller wrote:and never to pass an Out reference to anything that needs any In methods
Stevens Miller wrote:and to pass references to instances that implement both In and Out only to things that need both In methods and Out methods..
Mike. J. Thompson wrote:I'm not quite sure what problem it is you're solving here though, so I don't know if there is a better way or not.
"Il y a peu de choses qui me soient impossibles..."
Jason Bullers wrote:Create your base classes that implement In and Out, and then in all other classes that implement those interfaces, contain an instance of that base class and delegate to it.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:
Jason Bullers wrote:Create your base classes that implement In and Out, and then in all other classes that implement those interfaces, contain an instance of that base class and delegate to it.
That works, but it doesn't help me with type safety. The delegating classes don't yield true for delegatingInClassInstance instanceof In, or false for delegatingInClassInstance instanceof Out.
Stevens Miller wrote:Here's another idea I just tried, that does seem to work:
...
The classes that extend AbstractInOut declare themselves to be implementations of the interfaces they want holders of references to them to be able to use. If they are passed to those holders as instances of the interfaces they permit, those holders can't get access to the other methods in their superclass without an ugly cast.
Stevens Miller wrote:I think this solves my problem, but it decouples the actual implementation of the interfaces from the declarations, which seems risky to me. I can't imagine I'm the first Java programmer who wants to do this, so I'm looking for guidance on existing practices.
Stevens Miller wrote:
"Il y a peu de choses qui me soient impossibles..."
Mike. J. Thompson wrote:I think you missed the part of Jason's post where it says that the delegating types implement either In or Out, so they will in fact return true when used with the instanceof.
Stevens Miller wrote:I think this solves my problem, but it decouples the actual implementation of the interfaces from the declarations, which seems risky to me. I can't imagine I'm the first Java programmer who wants to do this, so I'm looking for guidance on existing practices.
Mike J. Thompson wrote:I'm not sure what you mean here. What declaration are you saying is being decoupled from?
Mike J. Thompson wrote:One final thing I would say here is that if the only code that is being shared is a specific field declaration and the setter for that field then this solution may well be more complexity than it's worth introducing. It may be better simply to duplicate the implementation of the setter in each implementation since it is so simple.
"Il y a peu de choses qui me soient impossibles..."
Stephan van Hulst wrote:Yes, you can still get access to the setOutData method by casting to the abstract base type, which is undesirable if the type is only supposed to represent an In.
"Il y a peu de choses qui me soient impossibles..."
Stephan van Hulst wrote:
"Il y a peu de choses qui me soient impossibles..."
Stephan van Hulst wrote:It doesn't really matter if you use visibility tricks, the whole idea of having something called "JustSomething" extend "SomethingAndSomethingElse" is exactly what causes black voodoo code. Don't do it.
"Il y a peu de choses qui me soient impossibles..."
Mike. J. Thompson wrote:Are you saying that the In and Out instances aren't really independent of each other and need to know each others internal state? If so then its probably time to reassess the design.
"Il y a peu de choses qui me soient impossibles..."
Stephan van Hulst wrote:The fact that AbstractInOut internally uses an In and an Out object to implement its interface is an implementation detail
"Il y a peu de choses qui me soient impossibles..."
Stephan van Hulst wrote:Your design is conceptually flawed.
You say Sources can't have Sources and Sinks can't have Sinks, but Sources must have Sinks and Sinks must have Sources. Therefore logically, Sources can't be Sinks and Sinks can't be Sources.
They can never be implemented by the same class. There is simply no way around this.
I find it questionable that Sources have Sinks (and vice versa). A source is a source and a sink is a sink. They don't have anything to do with one another. You retrieve data from a source and you put it in a sink. These types knowing of each other's existence sounds like the setup is too tightly coupled.
"Il y a peu de choses qui me soient impossibles..."
Stevens Miller wrote:
Stephan van Hulst wrote:The fact that AbstractInOut internally uses an In and an Out object to implement its interface is an implementation detail
I'm really not following you there, Stephan. They have to be the same instance, because I have objects that are going to be called on to implement both interfaces. Having two objects isn't an option, because the behavior of an object when accessed via the Out interface may depend on state that was set previously when it was accessed via the In interface.
Stevens Miller wrote:
Stephan van Hulst wrote:
What I'm actually working on is an implementation of the pipes-and-filters pattern. I have three classes: Source, Filter, and Sink. Every Source can generate data, and must have a Sink to send it to. Every Sink must have a Source, from which it will get data.
No more Blub for me, thank you, Vicar.
Mike. J. ThompsonThe [tt wrote:MyInOut[/tt] IS-A In and it IS-A Out. It is the MyInOut instance that is passed around when you have an object that needs to satisfy both the In and the Out interfaces, not the internal In and Out objects (which are just implementation details that it uses to satisfy its obligations under those interfaces, by delegating to them).
"Il y a peu de choses qui me soient impossibles..."
Mike. J. Thompson wrote:
This doesn't make sense to me, it sounds like the Source and the Sink do not fit together properly because their interfaces are in direct contradiction to each other.
1) The Source has-a Sink and sends data to it. This implies that the Source is in charge of the interaction, and the Sink is passive.
2) The Sink has-a Source and gets data from it. This implies that the Sink is in charge, and the Source is passive.
Obviously both of these situations can't be true, so I don't see why a Source has a Sink and a Sink has a Source. Only one of them needs to know about the other.
There is another option (that Stephan alluded to earlier). You could implement it such that the Source and Sink are not aware of each other at all and both act passively. This would require a driving class that reads from the Source, passes to each filter, and then passes to the Sink at the end.
"Il y a peu de choses qui me soient impossibles..."
chris webster wrote:Is this for a real application, or is it an intellectual exploration?
"Il y a peu de choses qui me soient impossibles..."
No more Blub for me, thank you, Vicar.
chris webster wrote:So... you're aiming to implement Reactive Streams (like Akka Streams), but you're using Java instead of Scala so you can't use traits for mix-ins. Good to have a hobby, I guess - have fun!
"Il y a peu de choses qui me soient impossibles..."
No more Blub for me, thank you, Vicar.
Stephan van Hulst wrote:Ins are Ins, Outs are Outs. Why do they have overlapping behavior? If they do, then why isn't this behavior documented in an even higher interface?
"Il y a peu de choses qui me soient impossibles..."
Stephan van Hulst wrote:I have to admit I stopped following the discussion when you dropped DirectShow. Not my area
![]()
"Il y a peu de choses qui me soient impossibles..."
Look! I laid an egg! Why does it smell like that? Tiny ad, does this smell weird to you?
Clean our rivers and oceans from home
https://www.kickstarter.com/projects/paulwheaton/willow-feeders
|