Difference between interface and abstracts

Python Help
1

Hi @all

Could you explain what is the actual difference between interface and abstracts in python programming, what we can achieve by using two?

What is the concept of oops behind the scene here?

How oops concepts is getting varied in python language?

Could you please guide me on getting good understanding on design principles and design Patterns.

2

“Interfaces” and “Abstract Classes” are features in many object oriented programming languages, but there isn’t an agreement across languages on exactly how they work. A language can not have these features and still be considered “object oriented”, and often different languages will give them different names.

So there are no strict definitions about what these terms mean. But there are general concepts that you can look for.

An “interface” is a description of what a type needs to be able to do, without any definition for how to do it. A common analogy is to think about the controls for a machine. You can see and touch the controls of the machine and you can know what the controls do - how they make the machine behave. But you don’t necessarily need to know anything about how the machine actually does the things the controls tell it to do. You can imagine keeping the same controls but upgrading the machine to a newer model - the insides of the machine all changed, but how you control the machine stays the same.

In OOP this usually means defining a type with just method signatures with no method bodies. In Java or C#, you use the interface keyword for this, in C++ there is no keyword but you can define “pure virtual” classes where all the methods don’t have implementations.

An “abstract type” or “abstract class” is a class where some of the methods don’t have definitions. Say you create a class with 5 methods, and you write the function bodies for 3 of the methods but leave the other 2 undefined. This creates a class that “has a hole in it”. A lot of the class is filled in, but there are parts left deliberately empty so they can be filled in in multiple different ways. It lets you write a class where you know some behaviors are always going to be the same, but specific parts will need to be different. You then “plug in” different versions of the abstract parts by creating different subclasses. In Java you use the abstract keyword for this, in C++ the virtual keyword.

There are many use cases for both of these patterns, and I would encourage you to search around online for examples (I think even Wikipedia can have good ones).

Now you might have noticed that I didn’t mention Python at all so far. :wink: This is because Python is one of those programming languages that doesn’t have either interfaces or abstract classes, at least not in the way Java, C++, or C# do.

  • Python is interpreted, not compiled. In those other languages, you need to explicitly write down your interfaces and abstract types so that the compiler can make sure that all the parts of your program fit together correctly.
  • Python is dynamically typed, not statically typed. In the other example languages, when you declare a variable you have to tell the compiler what type of value is going to be stored in that variable, and from then on in your program that is the only kind of value that you can put in that variable. Then the compiler checks all the places you assign variables and call methods to make sure that all the usages match their declarations. If a method says it takes a single string parameter, you can’t pass it an integer instead. In Python, variables don’t have a declared type. Values have types, but variables in Python are just names. You can name a value that happens to be a string, then later use that same name to refer to a number instead. You can write a function and say it takes one argument, but that argument could really be any kind of value. (You usually document what kinds of values you support, or check for them inside the function.)
  • Perhaps most importantly, Python’s object system is “duck typed”. What this means in practice is that when running a Python program, the interpreter doesn’t care what the class of an object is. Instead, it only requires that the object has the attributes you ask for. When you have some object named foo, and you write foo.myvalue, the interpreter basically just asks foo: “hello, do you have an attribute called “myvalue”? And if it does, then it gives it to you, and if it doesn’t, you get an error. Nowhere does the interpreter ask “foo” what type it is, or what class it was created from, or what other attributes and methods it has - it just tries to get the one attribute you asked for. And it does this every time you ask for any property or method of any object.

There are ways that you can use the object system to emulate things like abstract classes. (There’s even a nice standard library module for it.) They don’t work exactly like a Java abstract class, because Python fundamentally works differently than Java - things that Java does when compiling a program, Python either does not do at all (on purpose!) or checks while the program is running instead. But it can be a nice way to document things for other programmers and to check for mistakes when your program is running.

Python also has a system of type annotations, but that would be another long post so I won’t go there for now, haha.

1 Like
3

The question does not make any sense, but I can talk about the topic and explain some misconceptions, and may be that will be enough.

Some background first:

  1. Object-oriented programming (OOP) is a general idea about how to program. You can use it in many programming languages and it is nothing specifically about Python. There is no “behind the scene” that makes any sense here; it’s just a way that people design programs and talk about them.

  2. “abstract” is an adjective, not a noun - there aren’t such things as “abstracts”. I guess you mean either “abstract base classes”, or “abstract methods”, or both.

  3. The ideas of OOP don’t vary depending on the language. What varies is the actual code that you have to write in order to use them, and the extent to which they are supported.

  4. “interface” can be understood in a lot of slightly different ways. It can range anywhere from a specific feature of the language (Python does not have anything with this name) to just a word that means “the things you can do with an object” (so you can do this in any language that has “objects”, without even thinking about it) or even “the things you can do with some code that was provided to you, and the rules for how to use that code” (so you can do this in any language at all).

  5. “design patterns” does not mean very much. Originally, there was a book about how to write code in C++ in order to solve some design problems that are hard in C++, but very easy in many other languages. More importantly, it brought attention to some of those design problems, because people using some other languages didn’t even notice there was a problem to solve. Python is much more in the latter category (of course you pay for it in efficiency, but this is much less of a problem now than it was when C++ was dominant).

In languages where “interface” is a specific feature, usually it means something that looks like a class, but it only shows what methods there are and how to call them. It can’t contain any code for the methods, can’t be instantiated, and doesn’t say anything about the data that the instances contain.

In those languages, this is often used because the language does not support multiple inheritance, but it does allow you to implement multiple interfaces. This is one way to solve the so-called “diamond problem” (this is too complicated to explain here, please look it up separately). Python uses a different strategy for this problem, so it supports multiple inheritance, and does not need a separate interface concept.

Another reason for the interface feature is to formalize how we talk about the interface (in the ordinary sense) of a class. Python does not like that kind of formality; we just rely on the documentation instead. Sometimes it is useful to have code that can use unrelated classes, because they just happened to have methods with the right names that do the right things. When we discover something like this, we call those methods a protocol, and document the idea so that it can be used widely. We also design the language for this sort of thing in advance. For example, there is the iterator protocol that allows the code to use a for loop to loop over your object and have it act like a container. To do this you don’t inherit from any base class; you just implement the right methods with the right parameters and make them do the right thing.

An “abstract base class” is very similar to a language-supported interface. It’s one way to get a similar effect to an interface. But instead of “implementing” the interface (writing a class that has the methods that were described, writing all the code for them, making sure instances have the data they need etc.), you inherit from the abstract base class, just like an ordinary base class. Usually, the abstract base class is allowed to have some methods with code in them, to say what data an instance contains etc. You just can’t instantiate it.

Python does not quite have the usual sort of “abstract base class”. Instead, it has a standard library module called abc, that provides a way to fake them. You can inherit from abc.ABC and then that makes a class that works like an “abstract base class” for your other classes. There is not actually any restriction by default: you can create instances, have ordinary methods with code, etc. etc. But this does allow you to use the @abstractmethod decorator - and once there is an abstract method, you can’t instantiate it any more. In a child class, you need to implement that method, and then you can instantiate the child class.

1 Like
4

Thanks @flyinghyrax ,
Sorry to tell you , I could able to get some basic context like due to python is interpreted but Java is compiled one it is getting varied from other language.
But I couldn’t get on this context how abstracts is getting varied and what abstract plays a role here…