*morePure* SAM^functional interface]java

Most experts and authors on the internet don’t differentiate the 2. [[functional thinking]] says that a java 8 functional interface can have default methods in addition to a SAM (single abstract method)

Later, I will probably add a bit more details, but this is the key message.

Q: is a lambda related to SAM or FI (with default methods)? Official answer seems to be FI but can a FI-with-default-methods?

PURE-interface types ] c++^java

Someone pointed out

“The whole reason you have a special Interface type-category in addition to abstract base classes in C#/Java is because C#/Java do not support multiple inheritance. C++ supports multiple inheritance, and so a special type isn’t needed. An abstract base class with only pure virtual methods is functionally equivalent to a C#/Java interface.”…. actually with minor differences.

The sample code shows no special ctor, though the dtor is public virtual but without “=0” (not pure virtual), so I assume an “interface” type in c++ should have a virtual dtor, since it is designed to be subclassed.

Google style guide is more strict — A class is a pure interface if it meets the following requirements:

  • It has only public pure virtual methods, non-pure virtual destructor, and static methods
    • I feel the dtor should be empty since there’s no instance field.
  • It may not have non-static data members — same as java8 interfaces
  • It need not have any constructors defined. If a constructor is provided, it must take no arguments and it must be protected.

Simple, clean, pure Multiple Inheritance..really@@

Update — Google style guide is strict on MI, but has a special exception on Windows.

MI can be safe and clean —

#1) avoid the diamond. Diamond is such a mess. I’d say don’t assume virtual base class is a vaccine

#2) make base classes imitate java interface … This is one proven way to use MI. Rememer Barcalys FI team. All pure virtual methods, No field, No big4 except empty virtual dtor.

#2a) Deviation: java8 added default methods to interfaces

#2b) Deviation: c++ private inheritance from one concrete base class , suggested in [[effC++]]

#3) simple, minimal, low-interference base classes. Say the 2 base classes are completely unrelated, and each has only 1 virtual method. Any real use case? I can’t think of any but when this situation arises i feel we should use MI with confidence and caution. Similarly “goto” could be put to good use once in a blue moon.

SAM interface^lambda, across 3 languages

(In this discussion I suppose it’s probably OK to ignore the multicast feature of delegates.)

update — see java lambda and Single-Abstract-Method interface on http://www.oracle.com/technetwork/articles/java/lambda-1984522.html

I used to feel a (unicast) delegate TYPE is quite similar to a SAM interface. Now I doubt it.

C++ has abstract classes. When all the methods are pure virtual, that’s an interface (as in java). In this tradition, an interface is typically implemented by a Stateful class. Most textbooks and most schools introduce interface of this kind. What if the implementation class is stateless?

(To keep things simple let’s suppose there’s just 1 method.)  Then the objects needed by the method must be passed in. This feels like a static utility method without the static keyword. Such an interface is quite a different animal from the traditional interface. A non-capturing Lambda is the best example. But also
– static nested classes in java
– anonymous delegates

Where c# API uses a lambda, java often uses a SAM interface, since Java didn’t support lambda until Java 8.

I feel in both c# and c++, lambda is often used as a function argument (not “parameter”). Imagine you have a method parameter whose type is an SAM interface,
– and this interface has just 1 (or few) implementation(s)
– and the instance of this implementation class is basically stateless,

then this SAM parameter is probably a lambda trapped in an SAM. C# 3.0 and c++11 would set it free.

c++ pure-abstract-class == java interface


In C++ we generally separate a class into two modules: a .h module and a .cc module. The .h module contains the definition of the class, and the .cc module contains the definition of that class’s member functions. The definition of a class, in the .h module, contains declarations of all the member functions and member variables of the class.

This information goes beyond simple interface.

All the utility functions and private variables needed by the class are also declared in the .h module. These utilities and private variables
are part of the implementation of the class, yet they appear in the module that all users of the class must depend upon (via #include). Thus, in C++, implementation is not automatically separated from pure interface.

This lack of separation between pure interface and implementation in C++ can be dealt with by using purely abstract classes. A purely abstract class is a class that contains nothing (no fields) but pure virtual functions (ending in “=0”). Note Forward class declaration in effC++ can have fields, so those classes are usually not PAC.

c++ purely-abstract-class (PAC) == Java interface. SUN saw the value of PAC and made it a first class citizen in java.
c++ class definition + method definition == java class definition
c++ class with at least one pure virtual method == java abstract class

c++ forward class declaration == java no such thing
c++ regular class header file (without method definition) == java no such thing

In terms of compile-time dependency, java favors dependency-on-interface. In c++, you usually depend on *.h files, which is “thicker” than java interfaces. I feel there are 2 ways to reduce this tight coupling

* Forward class declaration

In java, as a “client” class, we can be completely oblivion of the actual type responding to OUR message. That actual type could be unknown at compile time. No recompile required when the actual type changes, since we depend on the interface only. I feel this is the dream of c++ developers.