Inheriting only interface

[jbzdak]

Recently, I have been learning Java (it is one of laboratories on my
department), well I know Java is awfully slow, but it is not the point
that I'm interested.
Java has a keyword "interface. (and if you know what it is skip this
paragraph), that is an abstract class, whose every function is public
and purely virtual, and every field is public and static. Java has its
own reasons for creating that keyword - you can only inherit from one
non-interface class, but from infinite interfaces.
The main question is whether using similar classes in C++ is considered
a good practice. I know that every abstract function has a small
overhead on every time you use it. But are there other cons?
I had an usage for it (in Java program). I had to manage a small
database, small enough to store it in a single file, and load it whole
into memory. I created an interface Product, that and implemented it in
SmipleProduct which is a straightforward , or even blunt,
implementation. And every function in SimpleProduct that would use an
instance of products gets a java-pointer to Product. Also I had a
couple of classes that used the Product interface. And I had created an
interface class for Product data base (that also gets only
java-pointers of Product)

Looks like that:
interface Product{
//(...)
}

class SimpleProduct{
SimpleProduct(P roduct foo){ /*(...)*/};
//(...)
}

interface ProductDataBase {
void add (Product);
Product findById(int id);
//(...)
}

And if I the database had grown a lot I would had just to re-implement
classes representing DataBase using for example mySQL. And whole GUI,
and classes used to compare
products would be left untouched.

The second question is whether it is possible to get similar result -
easiness of re-implementation of parts of program - using other,
better, techniques.

[Rolf Magnus]

jb****@gmail.co m wrote:

Recently, I have been learning Java (it is one of laboratories on my
department), well I know Java is awfully slow, but it is not the point
that I'm interested.
Java has a keyword "interface. (and if you know what it is skip this
paragraph), that is an abstract class, whose every function is public
and purely virtual, and every field is public and static. Java has its
own reasons for creating that keyword - you can only inherit from one
non-interface class, but from infinite interfaces.
The main question is whether using similar classes in C++ is considered
a good practice. I know that every abstract function has a small
overhead on every time you use it.
Well, usually you get an overhead if you call it through a pointer or
reference, but that would be the same for every virtual function, not just
pure virtual ones.
But are there other cons?
Well, a base class in C++ is more flexible. If you want, you can still write
some non-pure functions or add some member variables, but still derive from
as many of those classes as you want. Of course, with freedom comes
responsibility.
I had an usage for it (in Java program). I had to manage a small
database, small enough to store it in a single file, and load it whole
into memory. I created an interface Product, that and implemented it in
SmipleProduct which is a straightforward , or even blunt,
implementation.
Well, in C++, you could also put the implementation directly into Product.
Derived classes can still use that implementation for the parts where it
makes sense. Reducing code duplication is a good thing.
And every function in SimpleProduct that would use an
instance of products gets a java-pointer to Product. Also I had a
couple of classes that used the Product interface. And I had created an
interface class for Product data base (that also gets only
java-pointers of Product)

Looks like that:
interface Product{
//(...)
}

class SimpleProduct{
SimpleProduct(P roduct foo){ /*(...)*/};
//(...)
}

interface ProductDataBase {
void add (Product);
Product findById(int id);
//(...)
}

And if I the database had grown a lot I would had just to re-implement
classes representing DataBase using for example mySQL. And whole GUI,
and classes used to compare products would be left untouched.

Hmm, but wouldn't it be enough to just replace your DataBase class then? I
mean, what is the advantage of that interface now? It seems redundand. I
would use that interface approach if you have several implementations in
your program of which you choose one at run-time.