2020 Interfaces No Private Data

[thutch79]

I've begun to check out interfaces. I can definitely see the usefulness of these, but I'm puzzled why private data wasn't included in them. I agree more pure interface, abstraction layer, use cases don't need or want private data. But, one of the things specifically mentioned in the intro presentation was the ability to create "default implementations" within interfaces, so I can see that you intended them as more than just pure abstraction layers. Sometimes it would seem to make sense that the private data should be stored at the interface level, not the child class.

As an example, I believe Allen Smith talked about having an interface for a network endpoint. Seems like a great use case. Any actor could become a network endpoint without having to insert the class for network endpoint in the class hierarchy of the actor. You can have the connect//reconnect logic all built right in. However, the handle for the endpoint now needs to be owned by the child. Why should the child ever need to know about that handle? That should not need to be the concern of the child, right? That should live with the interface, not the child. Instead, you have to put that handle in the private data of the child, and create something like a reverse data accessor for the interface to access it.

Am I missing something obvious? I went through the "reasons behind the design" document, and Stephen didn't directly address this from what I can find. It's tempting to use an FGV in the interface to work around this, but that just feels wrong.

[tyk007]

---

@thutch79 wrote:

I've begun to check out interfaces. I can definitely see the usefulness of these, but I'm puzzled why private data wasn't included in them. I agree more pure interface, abstraction layer, use cases don't need or want private data. But, one of the things specifically mentioned in the intro presentation was the ability to create "default implementations" within interfaces, so I can see that you intended them as more than just pure abstraction layers. Sometimes it would seem to make sense that the private data should be stored at the interface level, not the child class.

As an example, I believe Allen Smith talked about having an interface for a network endpoint. Seems like a great use case. Any actor could become a network endpoint without having to insert the class for network endpoint in the class hierarchy of the actor. You can have the connect//reconnect logic all built right in. However, the handle for the endpoint now needs to be owned by the child. Why should the child ever need to know about that handle? That should not need to be the concern of the child, right? That should live with the interface, not the child. Instead, you have to put that handle in the private data of the child, and create something like a reverse data accessor for the interface to access it.

Am I missing something obvious? I went through the "reasons behind the design" document, and Stephen didn't directly address this from what I can find. It's tempting to use an FGV in the interface to work around this, but that just feels wrong.

---

Classes implement interfaces, just like they inherit from a base class. In your example, the child class is an instance of the interface. In that case, it is responsible in some way to represent the end-point. While it might use composition to do this (by delegating the work to another class) the interface isn't a composition mechanism.

Default implementation is an aid, under certain circumstances, to provide a useful static values in the cases where it is expected that not all implementations will not necessarily have a custom version (eg. standard configuration data).

[thutch79]

I understand what a true interface is. We have many interface classes already to allow for runtime injection as it is. I'm eager to get those converted to true interfaces now that the feature is available. Having them out of the class hierarchy will be great.

However, what I'm questioning is why they used something like network endpoint as a specific example when presenting it. It seems like a cool idea. Give whatever you want the ability to be a network endpoint with all the reconnect logic already built in. It just seems like that example is hindered by not be able to store the network handle in private data of the interface.

[tyk007]

I can't comment on the intent of the example (like you say, nothing is specifically laid out). Interfaces are about the caller, not the implementation, of course. 

It could be a single end-point class that takes in an interface object describing the "actor" with actions (such as a generic "Get", "Set" etc.). Then you implement those actions in each actor and add a factory method to the end-point class taking an instance of the "actor". Then the caller operates on the end-point class instead.

The extension point (seam) would be the flexibility to be able to turn any object that can implement the "actor" interface into an end-point with all the infrastructure logic as you described.

[rolfk]

An interface is, gasp, an interface. It holds no state whatsoever and hence also no data. If it would it would not be an interface anymore but a class. That is not different in other languages that have interfaces. In Java you have als an intermediate thing called an abstract class. Functionally it is pretty much the same as a LabVIEW class with "Must override" methods, with the caveat that even though it is normally never really called (but could through the Call Parent Method), you have to have an (empty) method implementation for it, which sometimes feels a bit cumbersome.

The other possible workaround to have a base class that provides this endpoint interface, won't work because you can't "attach" it to other existing classes except through composition but then your other class needs to have specific methods to deal with that.

What you would like to have for your situation is multiple inheritance, but that is a can of worms of its own. I have dabbled with it in C++ and would agree that there are probably not many people on this earth who really master that. It is in most cases a perfect recipe for creating a mess of a class hierarchy that gets more and more unmaintainable over time.

What tyk describes is probably one of the better approaches. It doesn't make an actor an endpoint but allows an endpoint to use an actor to do its thing. This does require a carefully designed actor interface and it won't be driven by the actor but instead simply use part of the actor interface. But in a way I think it would be a good thing to let the endpoint be the controlling entity of this functionality that uses an interface on the actor to do its magic.