> > However, I believe that functionality should > > not be inside an object, but inside these black boxes > > independant of the data they act on. > > This sounds interesting, can you provide any references > that give more detail and/or examples? Is there not a > widely accepted name for this? If not maybe this needs to > be described as a pattern and named. > > You are not suggesting this as a general solution for all > problsms, are you?
Well, in one way it should complement what's already available and in another it should define the way we write certain applications.
There are two issues at hand here.
1. Requirements. (What does this black box need to complete its operation?) 2. Input/Output. (What kind of data can it process and what format will it be when it comes out?)
Right now, interfaces define both the input and output. But the output is usually restricted to return values or "byref" parameters. That's not good. In C++, the return value isn't even part of the method's identity.
Seperation of functionality and its data is fundamental to any replaceable modularity. Why we would want to group them together is beyond me. Data should come in two types. One is data that gets passed around and the other is in more permanent storage (such as lists, arrays or even databases). When the data gets passed around, then it is given to "processing stations" that YOU the programmer have set up in a chain. So you can pick and choose the best algorithms and at the end of the chain, your data is in the form that you want it.
Some call all this component based programming, some stream based, some unix based, some pipeline based. There doesn't seem to be a consensus. All I know is that Unix style programming went to the wayside a long time ago for reasons unknown. It has proved itself time and again, but never got formalised. I'm sure people wanted more power and flexibility, but to throw it completely away was not the smartest move IMHO. It's a shame that OOP has made this kind of programming virtually impossible.
Its a little naive to think that a software component would behave like hardware. The term "black box" as a definition of a software component is a metaphor.
Interfaces provide several benefits. As noted, the interface provides encapsulation as it controls the access to the inner workings of software functionality. Also interfaces define a contract of services that an implementing component must provide. Interfaces (like in Java) or abstract base classes (C++) can be used to realize the true power of polymorphism. The true power of polymorphic components is decoupling. As far as I can tell, next to meeting the requirements of your product, decoupling is the most important consideration for any software design. Interfaces are not a panacea. Class, components and thier constituent elements such as interfaces go along way towards managing the complexity of software but software remains to be very complex indeed. Some of the arguments presented here seem to be advocating up front, UML based design. One of the primary benefits of UMLs class diagrams is to show associations between the various components of a software design.
IMHO the original comparison with an electrical component in a box is flawed logic in any case.
A box front panel should be likened to a UI layer not an Interface, the backside of the panel with wires is the UI linking to interfaces, the circuitry is the implementation of those interfaces.
I agree that the implementation of such interfaces can rely on many other objects and the underlying code may not be as loosely coupled as it would seem from the Interface layer but I think the initial comparison made here is a mistake.
I may be very stupid, but I can't see what the fuss is about. Can someone give me an example of these 'stealth interfaces' that are causing such excitement? Thanks.
> Seperation of functionality and its data is fundamental to > any replaceable modularity. Why we would want to group > them together is beyond me. Data should come in two > types. One is data that gets passed around and the other > is in more permanent storage (such as lists, arrays or > even databases). When the data gets passed around, then > it is given to "processing stations" that YOU the > programmer have set up in a chain. So you can pick and > choose the best algorithms and at the end of the chain, > your data is in the form that you want it.
I am interested in what you are saying here but I have some doubts about this.
I know that I can chain interfaces as they exist. I find that chaining of components is much simpler when the chain is unidirectional. What it sounds like to me is that you are talking about are bidirectional interfaces. In my experience, having bidirectionality in a design is generally to be avoideded. It increases coupling and the complexity of the system.
If I have three interfaces A, B, and C, I can easily chain them together by creating an implementation of A that accepts a B as a constructor and an implementation of B that takes a C as a constructor. How does what you are describing improve upon that?
> I may be very stupid, but I can't see what the fuss is > about. Can someone give me an example of these 'stealth > interfaces' that are causing such excitement? Thanks.
I should clarify that what Peter and I were talking about were not interfaces, in the sense of Java but rather:
"A point at which independent systems or diverse groups interact".
The interface of a class is traditionally thought of as being its public member functions and public fields. However, the classes that it depends on (i.e. uses, imports or inherits), are also part of its interface.
The analogy is akin to my printer in that it, it has on the front a power button, a form feed button, and a change ink button. However this is incomplete to describe the interface. The interface also include the power cord, usb printer cable, and paper feeder.
In a more concrete example:
class MyClass {
public myFunction() { }
private MyOtherClass myField;
}
Often people think of the interface of the class as being only "myFunction" but in fact it includes the dependency on "MyOtherClass". What can be a problem is that a call to "myField" could concievably result in a corruption of this.
> class MyClass {
> privatefinal MyOtherClass myField;
>
> public MyClass(final MyOtherClass backInterface)
> {
> myField = backInterface;
> }
>
> public myFunction() { }
> }
> > Why isn't the above a solution?
There really isn't a solution to be had. I am simply making the observation that a formal or informal specification of a class's 'interface' should also include the classes upon which it depends.
> There really isn't a solution to be had. I am simply > making the observation that a formal or informal > specification of a class's 'interface' should also include > the classes upon which it depends.
> > There really isn't a solution to be had. I am simply > > making the observation that a formal or informal > > specification of a class's 'interface' should also > include > > the classes upon which it depends. > > How does the above not do that?
What you posted was the class implementation, not a specification of the class's interface.
> > > There really isn't a solution to be had. I am simply > > > making the observation that a formal or informal > > > specification of a class's 'interface' should also > > include > > > the classes upon which it depends. > > > > How does the above not do that? > > What you posted was the class implementation, not a > specification of the class's interface.
I consider the constructor to be part of a classes 'interface'. Care to explain how it is not? You can just look at the signature of the constructor if the implementation is distracting.
If you are saying that we want to specify what an interface (in the Java sense) needs to work, I disagree. How would I know what someone else's implementation needs when specifying the interface?
/* [cdiggins] I am simply making the observation that a formal or informal specification of a class's 'interface' should also include the classes upon which it depends.
[James Watson] How does the above not do that? */
It does. But that's not the point. Taking out the "final" part also makes the same statement. The issue is that this is a detail many people overlook. If your text editor highlights the private parts of a class in chartruse, there's a chance you'll miss this, because it's just a detail that most of the time is overlooked because, most of the time, it's not important. But when it's important, you feel stupid for spending all your time chasing the wrong thing.
> It does. But that's not the point. Taking out the > "final" part also makes the same statement. The issue is > that this is a detail many people overlook. If your text > editor highlights the private parts of a class in > chartruse, there's a chance you'll miss this, because it's > just a detail that most of the time is overlooked because, > most of the time, it's not important. But when it's > important, you feel stupid for spending all your time > chasing the wrong thing.
I don't get your point. If the constructor requires an instance of the 'back interface' then how is it easily overlooked?
It doesn't make too much sense to me on the hardware side either.
If I were designing a microphone to be compatible with a particular amplifier, I would concern myself only with the electrical characteristics of the microphone jack (interface). The requirements of the "backside" (e.g. speaker outputs) would not be a factor, nor would the components used within the amplifier. All that would matter would be that the interface of interest be described correctly and that I met its requirements.
> It doesn't make too much sense to me on the hardware side > either. > > If I were designing a microphone to be compatible with a > particular amplifier, I would concern myself only with the > electrical characteristics of the microphone jack > (interface). The requirements of the "backside" (e.g. > speaker outputs) would not be a factor,
The speaker outputs is not analagous to the backside of an interface, because it has nothing to do with the microphone, it is part of the amplifier.
A better analogy is a pre-amplifier, which has an input, nobs and buttons (front-side) and an output (back-side).
Flat View: This topic has 46 replies
on 4 pages
[
«
|
1234
|
»
]
Previous Topic
