Good Coding practice with respect to interface versus class versus super class

Question

I am currently reading the following tutorial and have gotten up through here http://docs.oracle.com/javase/tutorial/java/concepts/interface.html

Maybe I should not be thinking about this question now because the tutorial hasn't brought it up, but I have a question of good practice. According to the tutorial up to this point, if I want to define an object and its methods, I can do so within either a class, or I can take parts of it that I expect it to share in common with other objects and put it in a super class. Or, from what I understand, I can do the former but delay defining my method until MAIN by using the interface keyword instead. I have two questions.

If I have a superclass->class structure, is it possible also to use a sort of "superinterface" instead to delay parts of the definition of methods until the MAIN method? (Please correct my terminology if you know what I mean, and know that I am not speaking correctly.)

Whatever is possible, when is it desirable to use each one from the perspective of efficiency and also of someone who would read my code?

I am a beginner. Thanks!

Edit: "Example" Code included (as written in the Netbeans IDE) for completion.

/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */
package javaapplication3;

/**
 *
 * @author Jeff
 */
class percolation{
    int site1 = 1;
    int site2 = 0;
    int site3 = 1;

    void changesite1(int newValue){
        site1 = newValue;
    }

    void changesite2(int newValue){
        site2 = newValue;


    }

    void changesite3(int newValue){
        site3 = newValue;
    }

    void printStates(){
        System.out.println("site1:" + site1 + " site2:" + site2 + " site3:" + site3);
    }
}

class extendedpercolation extends percolation{
    int site4 = 0;

    void changesite4(int newValue){
        site4 = newValue;
    }            
        void printStates1(){
            System.out.println("site1:" + site1 + " site2:" + site2 + " site3:" + site3 + " site4:" + site4);
        }          
}


class percolationdemo{
    public static void main(String[] args) {

        extendedpercolation perc1 = new extendedpercolation();
        extendedpercolation perc2 = new extendedpercolation();
        // Invoke methods on 
        // those objects
        perc1.changesite1(0);
        perc1.changesite2(0);
        perc1.changesite3(0);
        perc1.changesite4(0);
        perc1.printStates1();

        perc2.changesite1(1);
        perc2.changesite2(0);
        perc2.changesite3(1);
        perc2.changesite4(1);
        perc2.printStates1();
    }
}

Answer 1

You pretty much nailed it with your comment

Maybe I should not be thinking about this question now because the tutorial hasn't brought it up

It looks like you're on or near lesson 5, What is an Interface. I think your answer may be found on or near lesson 67, Interfaces. (I'm looking at the Table of Contents & just counting each line)

Quoting from that answer,

There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a "contract" that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group's code is written. Generally speaking, interfaces are such contracts.

For example, imagine a futuristic society where computer-controlled robotic cars transport passengers through city streets without a human operator. Automobile manufacturers write software (Java, of course) that operates the automobile—stop, start, accelerate, turn left, and so forth. Another industrial group, electronic guidance instrument manufacturers, make computer systems that receive GPS (Global Positioning System) position data and wireless transmission of traffic conditions and use that information to drive the car.

The auto manufacturers must publish an industry-standard interface that spells out in detail what methods can be invoked to make the car move (any car, from any manufacturer). The guidance manufacturers can then write software that invokes the methods described in the interface to command the car. Neither industrial group needs to know how the other group's software is implemented. In fact, each group considers its software highly proprietary and reserves the right to modify it at any time, as long as it continues to adhere to the published interface.

As you can see, interfaces are used to promise that certain classes will always have certain properties and/or methods.

To make the tutorial example more concrete, just understand that all classes (e.g., Tesla, BMW, Mercedes, Toyota etc.) that implement the IAutonomousControls interface are guaranteed to have all the properties and methods (stop(), start(), turnLeft(), honk()) that are defined in that interface.

Exactly how those properties and methods are implemented are not defined and may be different from class to class.