What does the word "state" mean?

Abstract classes on the other hand, while also not being able to be made into objects by themselves, can contain lots of code. They can contain fully functional methods, fields, internal classes etc. You then use them as an extension to create already mostly functional classes. It's a complex topic and will become more clear as you start running into problems that are solved with them. Without that context it is a very nonsensical topic. (i typed the code above out without an IDE, so i apologize if there are any errors)

Thank You very much! I understand the working of your example-code. I think i understand how work the interfaces and abstract classes and the inheritance. (I often make own example-codes for myself, and i monitor the workings of them. It helps a lot to understand things better.) But something is missing yet. I don't understand this expression: "interface has no state. But an abstract class includes state." But what kind of state is included or not? state = what? Please, with other words:-) Maybe: if something has/includes state, then this word with other words just means we are able to create objects from this something? Or, maybe: if something has state, it means we already have an object created from that something? Or, maybe, if something has no state, then we say this because of its methods can't include any code? Or, maybe, we say "an interface has no state" because of it can't have instance-variables but can have only methods? Or, the "state of something" means the state of a created object? (Are there already initialized its instance-variables or not; its instance-variables was setted to what value, etc.)

I think i found the answer on a site: "Software objects also have a state and a behavior. A software object's state is stored in fields and behavior is shown via methods." So, the instance-fields of a class are also known as "states". I didn't know it... Maybe i know what is "state" already... But in the lesson there was this example: ( https://codegym.cc/groups/posts/104-the-difference-between-abstract-classes-and-interfaces )

public interface CanFly {
   String species = new String();
   int age = 10;
   public void fly();
}

The lesson says: "An interface only describes behavior. It has no state." But what are they in this interface here? String species and int age. Then what are they? Not instance-variables? So these are two states inside the interface. This is a confusing contradiction for me.

The thing about the fields of interfaces is that they are static final (read only). They are hard coded and can't be modified in code like a normal variable. So with that interface, if you created a class that implements it:

class myClass implements CanFly {

    public void fly() {
        System.out.println("Flying");
    }
}

Then in a main method:

public class Solution {
    public static void main(String[] args) throws IOException {
        CanFly test = new myClass();
        System.out.println(test.age); // works by calling it from object
        System.out.println(CanFly.age); // works by calling it as static
        test.age = 15; // error on this line because value is read only
    }
}

You would have to comment out that one line for the code to compile. Before enums were introduced, people would create interfaces that were nothing more than read only values.

It still goes back to the fact that interfaces are completely useless constructs UNLESS you implement them on many similar classes. If you only implement an interface on one class that would only make more work for you to do. Iterator is an interface that all the storage classes of the Collections library implement (Lists, Sets, Vector, maps, trees, etc). Take this example:

public class Solution {
    public static void main(String[] args) throws IOException {
        Vector<String> v = new Vector<>();
        TreeSet<String> ts = new TreeSet<>();
        ArrayList<String> al = new ArrayList<>();
        LinkedHashMap<String, String> lhm = new LinkedHashMap<>();
        LinkedBlockingQueue<String> lbq = new LinkedBlockingQueue<>();

        printCollection(v.iterator());
        printCollection(ts.iterator());
        printCollection(al.iterator());
        printCollection(lhm.keySet().iterator());
        printCollection(lhm.values().iterator());
        printCollection(lbq.iterator());


    }

    static void printCollection(Iterator it) { // use a standard data accessing interface
        while(it.hasNext()) System.out.println(it.next());
    }
}

All these classes, while they all have different methods to store and retrieve data, all share a standard data retrieval interface, Iterator. I made one method that could read the data stored in any one of these classed (and any other Collection class too). This was instead of writing 5 different overloaded printCollection() method. The interface does nothing though, it is just a contract that the class that implements it will have the methods described by the interface. It is up to the class designer to implement the methods so they do something.

If you code just for you then interfaces aren't that oftenreally needed. If you code a package that other packages access you can use an interface to manage encapsulation. All methods and fields are package private, the methods of the interface have to be public. So they define your business logic. That's probably the easiest case of an interface. In addition to that you use a factory method to build objects. Then users of your class even do not need to know your class' name. Knowing the interface is enough.

Thank you very much!! So the variables in the interface are always static - so they are always only class-field. And final. - I understand. (But now I’m mad to CodeGym for they not be able to tell us such very simple things in lessons.)