In OOP, can an interface have attributes?

Asked

Viewed 5,548 times

17

Is it possible for an interface to have attributes? If not possible, why not?

oop interface

2 answers

16


An interface is a "purely abstract class", which only specifies a guy but not the concretization. When we speak of "attribute" in OOP we are usually referring to a concrete field - a memory position so to speak - which is an implementation detail (Note: controversial definition, but mistakenly used everywhere, so I will use the term "field" and not attribute).

However, if we imagine "field" as "something a class needs to have" - like, a date needs to have year, month and day, but no matter how it is represented in memory - then it would be possible for a field to be part of the specification of a type. As far as I know, none of the OOP languages working with the concept of "interface" allow this (at most you can have getters and setters as part of the interface), but it’s a possibility, I don’t know how it would work in practice.

  • +1 for the definition of 'interface as contract'.

  • @mgisonbr, your answer is in accordance with what was asked. I just don’t agree at the moment that you say "An interface is a 'purely abstract class' ". I wouldn’t do this because an interface is actually a contract, it’s a behavior that a class should follow and all the methods that the interface states should be enforced.

  • The abstract class is a type of class that can only be inherited and not instantiated, in a way it can be said that this type of class is a conceptual class that can define functionalities so that its subclasses can implementthem on a non-compulsory basis.

  • 2

    @Luãgovindamendessouza What is the difference of this that you spoke to a purely abstract class? Each abstract method in an abstract class represents a contract, but it can also have concrete methods and/or attributes. Eliminate the concrete methods and attributes, and we have an interface. It’s just not the same because you can implement more than one interface - but not inherit from more than one class - but it seems close enough for comparison purposes.

  • 2

    (Note: I spoke thinking about Java, other languages can allow multiple inheritance. And since I’ve touched on that, interfaces in Java 8 can also have default methods, which also define "features so that your subclasses can implement them in a non-essential way". It seems very similar for my taste...).

13

Before we establish the correct term: What is the difference between attribute and field in the classes?.

In general, no. But nothing prevents a language from determining that it can. It would probably cease to be exactly an interface, even if it kept the name. In fact some languages have done this (Java, C#, Kotlin, Swift)

That being said, it is possible to have languages that can almost have this and correctly.

C#, for example can have properties. Property is nothing more than a couple of methods (getter and Setter) and that have a field (general term used) supporting its value. Note that in the background the field will only exist in the class where the interface is implemented, it will not exist in the interface.

I know Ruby has something similar.

And I agree with mbigsonbr’s response. If we are talking about fields as a conceptual term that indicates a feature that the class should have, it is possible to put on the interface some way that indicates this, even if there is no mechanism in it that puts a variable to store this state.

For example, in Java it is possible to indicate this by doing

interface Tax {
    BigIntenger getTax();
    void setTax(BigInteger tax);
}

There is the problem of who will implement this interface in the concrete class how will store the data and how the methods will work.

You can’t because interface is just a contract, it’s not to have detail of how each thing should work. Anyone who implements this in the class can choose another way to store the data.

Then it’s worth going over the other question Programming for interface and not for implementation, why?. Doing this makes it more flexible. It is preferable to just say what need to do and not as need to do. So you can exchange components more easily. If there were implementation detail within the interface, it would be less flexible on how it can work. Note that in the above example the type BigInteger was used in the contract. Nothing prevents the type actually saved from being of another type that is more interesting in a given situation. noticed the flexibility? You can use the creativity there.

  • 2

    +1 for clarification (which many developers seem to ignore) regarding the implementation of setters and getters.

Browser other questions tagged oop interface

You are not signed in. Login or sign up in order to post.