Abstract and Interface difference

I kept looking at the Head First Book and wanted to know the difference between an Abstract Class and an Interface.

I asked ChatGPT to tell me the difference.   It explained what each one does and gave sample code.  I have known that part from the book.   I cant see the difference between them except that the interface can implement multiple classes.   I don't know what that would look like.    

The last paragraph from ChatGPT says is pasted here for reference.   I bolded the parts of the text that I need an example for.  I'll look in the book to see where it has two or more classes being implemented at one time.

In summary, abstract classes provide a way to define common behavior and characteristics while allowing for inheritance and code reuse, while interfaces define contracts and allow for multiple inheritance of behavior among unrelated classes. Abstract classes are useful when you have a common base for related classes, whereas interfaces are useful when you want to define a common API for unrelated classes to adhere to.

I'm brain storming here.  
The abstract class contain instance variables and method headers (contracts).  They cannot directly be made into objects.  A second class needs to extend it.  In the extension the methods will override the abstract class

The interface can inherit from multiple classes.  I don't know what that looks like.  It has some rules about constants being static and final. The methods are public.  They don't have instance variables.

They seem so much alike except that the interfaces can inherit from multiple classes.

I always find it's helpful when learning new language features to see a real example of the feature. Seeing a description like you just gave, I don't find that helpful. Do examples not work for you?

Also the fact that a class can implement more than one interface (which isn't what you said) is not a key feature of interfaces and it's not a reason to choose to write an interface rather than an abstract class. People obsess over that because in the old days people grossly overused inheritance instead of composition, which led them to want to inherit more than one superclass.

You read that an interface "defines a contract" but I think that didn't mean anything meaningful to you. Here's an example, then.

If you write a GUI program in Java then you'll be using Swing. You haven't got into that yet, I expect, but since it's a GUI you'll expect it allows you to display buttons which the user can click on, and then the user expects something relevant to happen. This class is called JButton. Don't look it up, it has an eye-watering number of methods and you don't need to know any of that. A JButton can be clicked and then some code will run to do the thing the user wanted done.

Now, they could have designed JButton so you could subclass it and override the (just made up by me) "whenClicked()" method with that code. But that wasn't what they did. They provided an interface named ActionListener. Here's what it looks like:

public interface ActionListener {  void actionPerformed(ActionEvent e); }
It's an interface, so we're going to write a class which implements it. Let's call that class Worker. Then there's going to be a contract between Worker and JButton: If the JButton is clicked then it will call Worker's actionPerformed method with a parameter explaining what happened (that's the ActionEvent). And to set up that contract we need to connect a Worker object to the JButton: it has a method named addActionListener(ActionListener) for that. Since Worker implements ActionListener we can say that a Worker IS-A ActionListener, and therefore we can pass a Worker object to the JButton using its addActionListener method.

Here's what that class might look like:
public class Worker implements ActionListener {  void actionPerformed(ActionEvent e) {    System.out.println("The button was clicked");  } }
And here's how we might use it:
JButton clickMe = new JButton("Click here"); clickMe.addActionListener(new Worker());
Now in real life it isn't usually worth creating a whole class for that, so we use anonymous classes or method references, but don't worry about that yet, it's still the same contract being made between two objects using an interface.

Paul,

The interface looks a lot like using an abstract class and then using Extends in the class that uses it.  What is the difference?

I followed the code up to the last line:

clickMe.addActionListener(new Worker());

I suppose there is a class named clickMe that has an addActionListener method.  new Worker() calls the "class Worker implements ActionListener".   The parameter of  clickMe. addActionListener() is new Worker().   How does new Worker know which method to run (if there was more than one method in the class)?

Thanks,

Kevin

Paul,

Oh wait...

clickMe.addActionListener(new Worker());

clickMe is not a class.   It is a variable of type JButton.

The JButton must have a class named addActionListener.   addActionListener would have a parameter to tell it which class to use.  It would be Worker().

Am I getting closer?

Thanks,

Kevin

kevin Abel wrote:I asked ChatGPT to tell me the difference.

I strongly implore you to stop using ChatGPT as a learning material. It's a useful tool when you already know what you're doing, but when you're still learning you won't be able to tell the sense from the nonsense. ChatGPT suffers from so called "hallucinations", where it will make up a fake answer if it can't arrive at a factually correct one.

In this particular case, the answer was pretty good, but there will be times where it gives out a blatantly false answer, and it will only confuse you more.

I'll look in the book to see where it has two or more classes being implemented at one time.

The interface can inherit from multiple classes.

You keep using the terminology the wrong way around.

Concrete classes aren't "being implemented". They "implement". So you can look for examples of two or more classes "implementing" a common base class.

Similarly, an interface doesn't "inherit from multiple classes". A class can implement/inherit from multiple interfaces.

They seem so much alike except that the interfaces can inherit from multiple classes.

You need to stop looking at the technical differences, and start looking at the conceptual differences.

When you write/use an interface, you're saying: I need something that implements this contract, but I don't really care who implements it, or how they implement it.

When you write an abstract class, the primary purpose is different. You're saying: "I expect two classes to be very similar in implementation, so to make their live easier I will provide a base implementation that they can both inherit.

How does new Worker know which method to run (if there was more than one method in the class)?

It doesn't, and it doesn't have to. It's the code inside of the JButton that decides which method of the Worker to call.

Here is what such code might roughly look like:
public final class ExampleButton {  private final List<ActionListener> listeners = new ArrayList<>();  public void addActionListener(ActionListener listener) {    listeners.add(listener);  }  ...  private void fireActionEvent(ActionEvent event) {    for (var listener: listeners) {      listener.actionPerformed(event);    }  } }
As you can see, when an event is fired, the button explicitly calls the actionPerformed() method on every listener that you registered. So even if ActionListener had more than one method, there would be no ambiguity, because the button itself decides which method to call.

Note that the button knows nothing about the Worker class. It only uses the ActionListener contract. By implementing ActionListener, Worker promises to do the things that a button expects from an ActionListener.

The JButton must have a class named addActionListener.

It must have a method named addActionListener(). Again, be careful with your terminology.

addActionListener would have a parameter to tell it which class to use.

It's better to say that it has a parameter that tells it which "implementing instance" to use.

Remember, you're passing it an object reference. The object must be of a type that implements ActionListener. In this particular case, the object is of type Worker, which implements ActionListener.

kevin Abel wrote:
The interface looks a lot like using an abstract class and then using Extends in the class that uses it.  What is the difference?

Kevin,

Since you keep asking about the difference between the two I think it would help to understand the historical intent between them and conceptualize them from that perspective instead of getting bogged down in code.

The main idea to focus on is "how much code does each type allow that is concrete/implementation code"?

An abstract class has a ratio of implementation to abstraction that can vary from 100 to 0.

An interface has a ratio of implementation to abstraction that is exactly 0. (More accurately, "was" 0. More on that later).

The Java designers deemed the situation special enough and useful enough for a type definition to have absolutely no concrete implementations but to define method signatures for it to be designated as its own kind of type.

Why? The language does not allow multiple inheritance, but with this layout of available types-of-types, the language can reap the useful benefits of multiple inheritance (only the behavior contract / non-stateful portion) but not suffer the negatives of multiple inheritance.

Why? Because when defining only method signatures (behaviors) you won't end up with a diamond problem and it allows linking worker classes together with a lot of compile-time safety when passing arguments around.

Why still? It'll be hard for you to see the benefits further before diving into generics, complex architectures, and maintainable / extensible frameworks. When you start using libraries that make use of both types it will eventually click with you why would use one rather than the other. At this point you're a chef who only knows how to make a few simple dishes, it'll be difficult to understand why the kitchen has so many pots and pans with little differences.

(Note: the ratio explanation above is not accurate anymore with newer versions of Java allowing default methods in Interfaces, but how the language reached that feature is a different topic)

Welcome to the Ranch

JZ: KA is having enough difficulty without coming across new concepts like diamond inheritance.
The simple thing is that an abstract class is one not intended to be instantiated as is. You must create subclasses from it and those subclasses can be declared abstract or can be instantiated.
Example:abstract class Vehicle { ... }class Car extends Vehicle { ... }class Bus extends Vehicle { ... }class Motorcycle extends Vehicle { ... }class Lorry extends Vehicle { ... }

abstract class Animal { ... }abstract class Fish extends Animal { ... }class Trout extends Fish { ... }class Herring extends Fish { ... }class Shark extends Fish { ... }class Lamprey extends Fish { ... }You are not allowing Vehicle, Animal, or Fish to be instantiated directly, but you can instantiate Bus, or Lamprey, or six others. An abstract class may contain abstract methods, but doesn't have to contain any. A concrete class isn't allowed any abstract methods.

Stephan,

I keep reading this part:



Stephan,

I made some pictures below so you can know how I am reading the words.  Is it close?

You keep using the terminology the wrong way around.

Concrete classes aren't "being implemented". They "implement". So you can look for examples of two or more classes "implementing" a common base class.

interface A

class B implements A  
Class C implements A  
class  D implements A

Similarly, an interface doesn't "inherit from multiple classes". A class can implement/inherit from multiple interfaces.

interface  E          interface F         interface G  <--first I create the interfaces

Class all_together_now  Implements interface E, interface F, interface G  <--The concrete class

Stephen,

You need to stop looking at the technical differences, and start looking at the conceptual differences.

When you write/use an interface, you're saying: I need something that implements this contract, but I don't really care who implements it, or how they implement it.

I am a chair.   I exist.  A movie theatre, a restaurant,  a  desk   can utilize me and I don't care what or where I will be used.  

When you write an abstract class, the primary purpose is different. You're saying: "I expect two classes to be very similar in implementation, so to make their live easier I will provide a base implementation that they can both inherit.

I'm a "plant cell"
I can become a root cell  OR a leaf cell OR a flower cell

Question:  Why does "plant cell" have to be marked as abstract?  Can't any class be inherited even without it being abstract?

Thanks,

Kevin

Paul, J Zal, Campbell,

Please allow me to chat with Stephan for a while in this thread.  I'll go back to reading your posts after.  I'm getting mixed up jumping from one thought to another.

Thanks,

Kevin

kevin Abel wrote:Class all_together_now  Implements interface E, interface F, interface G

To be syntactically correct and following normal naming conventions it would be like this:class AllTogetherNow implements E, F, G

Similarly, an interface doesn't "inherit from multiple classes". A class can implement/inherit from multiple interfaces.

*** WARNING *** Reading this may add to the confusion.
Although the following is true,  I have NEVER seen this in production code.
An interface MAY inherit (extend) from one or more interfaces.
/* * https://www.tutorialspoint.com/why-an-interface-cannot-implement-another-interface-in-java * An interface cannot implement another interface in Java. * *   An interface in Java is essentially a special kind of class. Like *   classes, the interface contains methods and variables. Unlike *   classes, interfaces are always completely abstract. *   *   An interface is defined just like a class except for the keyword *   interface in place of a class, the variables are declared in an *   interface are static and final and the methods are defined in an *   interface are public abstract methods. *   *   An interface can extend any number of interfaces but one interface *   cannot implement another interface, because if any interface is *   implemented then its methods must be defined and interface never *   has the definition of any method. *   *   If we try to implement an interface with another interface, it *   will throw a compile-time error in Java. */ //---------------------------------------------------------------------- public class TryInterface { public static void main( String[] args ) { MainClass main = new MainClass(); main.printAx(); main.printBx(); main.printCx(); } } //---------------------------------------------------------------------- class MainClass implements Cx { // All three methods MUST be defined @Override public void printAx() { System.out.println( "A" ); } @Override public void printBx() { System.out.println( "B" ); } @Override public void printCx() { System.out.println( "C" ); } } //---------------------------------------------------------------------- interface Ax { void printAx(); } //---------------------------------------------------------------------- interface Bx { void printBx(); } //---------------------------------------------------------------------- interface Cx extends Ax, Bx //  "extends" not "implements" { void printCx(); }

Stephan.    
I read Campbell's explanation about abstract classes.  It cannot be run like a static class or be instantiated as an object that can be run.  

I now understand how abstract works except for wondering why a non-abstract class couldn't do the same thing.  Couldn't we declare methods that are empty in a non-abstract class,  use inheritance and overwrite the methods in the children?

I am still baffled by interfaces.   I will take a break and read all of this thread again.

Thanks everyone,

Kevin

Ron,

Your syntax for implements looks like examples I have seen and it was good that you pointed that out.

Thanks,

Kevin

kevin Abel wrote:Couldn't we declare methods that are empty in a non-abstract class,  use inheritance and overwrite the methods in the children?

If they return a value they can't be empty. If they aren't abstract then the compiler won't enforce the subclasses to implement them.

Carey,

I'll skip reading your post since I'm guessing it is an exception case or something special.    

Thanks,

Kevin

kevin Abel wrote:. . . Campbell's explanation about abstract classes.  It cannot be run like a static class or be instantiated as an object that can be run.

We have never mentioned static classes, but that phrase is confusing and we don't use it.
You can run neither classes nor objects. You can only run methods.

. . . . Couldn't we declare methods that are empty in a non-abstract class,  use inheritance and overwrite the methods in the children? . . .

You can only have empty methods if they have void instead of a return type. I think the answer to your question is, “usually no”.

Thanks everyone,

Kevin

That&apso;s a pleasure

Kevin, it's not clear what you mean by an "empty" method.  I think Campbell believes you mean something like this:
public class Foo {  public void someMethod() {    // empty == no code in the body of the method  } }
However, is it possible you mean something like this?
public abstract class Foo {  public abstract void someMethod();  // empty == no braces or block at all for an abstract method }

Mike,

I was thinking of the top one

public class Foo {  public void someMethod() {    // empty == no code in the body of the method  } }

Can a class without the word abstract be inherited by the subclass?

Thanks,

Kevin

Campbell,

I understood abstract when you gave an example
Post Today 11:13:44 AM     Subject: Abstract and Interface difference
JZ: KA is having enough difficulty without coming across new concepts like diamond inheritance.
The simple thing is that an abstract class is one not intended to be instantiated as is. You must create subclasses from it and those subclasses can be declared abstract or can be instantiated.
Example:

abstract class Vehicle { ... } class Car extends Vehicle { ... } class Bus extends Vehicle { ... } class Motorcycle extends Vehicle { ... }

Is there a way to show interface and implements in this style?  

Easiest way is by hand, like you just did.

If you wanted a project to work on you could write a parser that would find all .java files and pull those out of the code. (Easier said than done.)

kevin Abel wrote:I am a chair.   I exist.  A movie theatre, a restaurant,  a  desk   can utilize me and I don't care what or where I will be used.

No. It's not the chair that doesn't care how it is used. It's the restaurant, movie theater or desk that doesn't care how the chair ensures that people can sit on it, as long as people can sit on it:
interface Seat {  void accomodate(Person person); } final class Chair implements Seat {  @Override  public void accomodate(Person person) {    // implementation of a chair here  } } final class Stool implements Seat {  @Override  public void accomodate(Person person) {    // implementation of a stool here  } }final class Restaurant {  private final Queue<Seat> emptySeats;  private final Collection<Seat> takenSeats = new ArrayList<>();  Restaurant(Collection<? extends Seat> seats) {    emptySeats = new ArrayDeque<>(seats);  }  void seatDiner(Person diner) {    var seat = emptySeats.remove();    seat.accomodate(diner);    takenSeats.add(seat);  } }
In the example above, the Restaurant doesn't care whether its seating arrangement consists of chairs or stools or maybe even some other kind of seat. It only cares that the seats can accommodate diners. That requirement is expressed by the Seat interface. As you can see, a Seat doesn't have an implementation. It only declares the accomodate() method. That's all that the Restaurant needs. That's what interfaces are for.

It's the same with JButton and ActionListener. The ActionListener interface is there so that JButton can call the actionPerformed() method. JButton doesn't know about Worker. How would JButton call the actionPerformed() method if there wasn't an ActionListener interface?

I'm a "plant cell"
I can become a root cell  OR a leaf cell OR a flower cell

Question:  Why does "plant cell" have to be marked as abstract?  Can't any class be inherited even without it being abstract?

I now understand how abstract works except for wondering why a non-abstract class couldn't do the same thing.

Presumably, PlantCell contains some method that it can't implement, because the implementation depends on the specific type of plant cell. If it can't implement a method, then it must be abstract.

Couldn't we declare methods that are empty in a non-abstract class,  use inheritance and overwrite the methods in the children?

Sure, but why would you do that? That way, you'd just run the risk that people forget to override the method.

If the method is abstract, then there is no risk of people forgetting to implement it. You MUST implement it, otherwise the application won't compile.

I watched this video on YouTube about interfaces.  I understand it but want to make sure it is correct.    If anyone has interest could you tell me if it is accurate?

https://www.youtube.com/watch?v=GhslBwrRsnw

final class Restaurant {  private final Queue<Seat> emptySeats; //  <--- I can tell that emptySeats is something that won't vary.   I don't know what kind of data structure Queue<Seat> is.  private final Collection<Seat> takenSeats = new ArrayList<>();  // I know that a Java Collection groups objects and lets us manipulate them.  (I Googled).  I don't know enough to understand this line. I recognize the <> operator so                                                                                                                 //maybe the line expands to:   private final Collection<Seat> takenSeats = new ArrayList  Collection();  I still don't know what it does.  Restaurant(Collection<? extends Seat> seats) {  // I don't know the <? operator    emptySeats = new ArrayDeque<>(seats);  // I think that this is taking the array of seats and copying it into emptySeats which must also be an array.  } //Are the above lines instance variables?    void seatDiner(Person diner) {    var seat = emptySeats.remove();  // the last seat in the emptySeats is removed and the remainder of emptySeats is put into the seat variable.  seat is spelled in lowercase so i know it is not the same as the seat interface.    seat.accomodate(diner);  // perhaps a seat in the array/collection seat is calling the method in the seat interface?      takenSeats.add(seat);    } }

Everything before the Restaurant class made sense.   I have very little idea after that.  

kevin Abel wrote://Are the above lines instance variables?

Well, they're not "static"....

I think the easiest way to understand this is by saying a Class is basically a custom data type. Like you have generic types int, double, string, and so forth, but Class lets you create your custom type to represent an "object" like a car.  A specific type of car, like a ford mustang, could be derived from a generic class Car. An interface could be provided that guarantees the features in that vehicle. The interface could also be given to a motorcycle which isn't even a type of Car! The interface isn't a data type, it is not a car or motorcycle, it's more like a description of what features the object needs. A reason to use interface is for example, prevent you from building a car which doesn't have any brakes. The interface should guarantee that all the basic features needed by a vehicle are there. There would be a method signature there saying "brakes" and the interface would force you to implement that method in your class, you'd have to write that method from scratch if it didn't exist somewhere already, and you can't compile the program until you implement every single method specified by the interface.

I watched a few YouTube videos regarding abstract classes and interfaces.   This is a high level of what I understand:

abstract classes
You cannot instantiate them.   myObj = new someAbstractclass;  wont compile.
Abstract classes can have some or all of the methods be Abstract.
Another class extends the abstract class.  The  methods that have code between the squiggle brackets are inherited and can be used as is or they can be overwritten.
The abstract methods have to be overwritten and given a body with code between its squiggle brackets.

interface
These can not be instantiated either.
None of the methods can have a body.
one or more interfaces can be implemented in a different class
Each method has to be overwritten or the compiler will complain.
Interfaces are a contract.  The classes that uses them must give a body to each of the methods.

This is how much I understand and I hope I have this part accurate or very close.

Then there is a big jump for me when it gets to other details that all of you and the book are explaining.  

Ill read the sorting chapter again and also this thread to see what else I can understand.

AFter that I'll write some code and explore.

There are about 20 questions in the sort chapter in the book.  They don't make any sense to me now.  I'll try them on my own and then start a new thread just for the questions.

Thanks all of you continuing to have patience with me.  Once I understand all of this I'd like to make a YouTube video from an amateur's point of view. I have been in situations where others hit a "wall" and go another direction or give up.  I like to keep working at it.  

I have been reading all of the posts.  Sometimes they don't make sense until I understand what something means.  For example signature and contract were strange until I caught on.  

Thanks to all of you not abandoning me.  

Kevin

kevin Abel wrote:I watched a few YouTube videos . . .

Beware. I have seen vey few YouTube videos that even approach being any good. Most aren't actually wrong, but some are. Most are incomplete and assume their viewers know much more than they actually do.

kevin Abel wrote:abstract classes
You cannot instantiate them.   myObj = new someAbstractclass;  wont compile.
Abstract classes can have some or all of the methods be Abstract.
Another class extends the abstract class.  The  methods that have code between the squiggle brackets are inherited and can be used as is or they can be overwritten.
The abstract methods have to be overwritten and given a body with code between its squiggle brackets.

interface
These can not be instantiated either.
None of the methods can have a body.
one or more interfaces can be implemented in a different class
Each method has to be overwritten or the compiler will complain.
Interfaces are a contract.  The classes that uses them must give a body to each of the methods.

Seems like you have the concepts now but I'm disturbed by your imprecise use of terms.

Java has nothing called "overwritten", it has "overridden" and "overloaded".
"{}" are  called "braces", not "curly braces" or "squiggle brackets".
"[]" are called "brackets", not "square brackets".
Writing a method without a body is a "declaration", or to "declare" a method.
Writing a method with a body is a "definition", or to "define" a method.

It's good to see you making progress.

Campbell wrote:Beware. I have seen vey few YouTube videos that even approach being any good. Most aren't actually wrong, but some are. Most are incomplete and assume their viewers know much more than they actually do.

The two YouTube videos on interfaces were close in information.  

When watching YouTube videos I'm often concerned that the person making them is mostly wrong.    The videos had less details but nothing went against what all of you on Code Ranch were writing to me.

Here is my first instructional video that I created six months ago.  It's for installing a new back up camera in my car.  I tell the audience that I was learning as I went along.  I was surprised to get thousands of views.

https://www.youtube.com/watch?v=h4JdOlUsKaU&t=110s

Thanks,

Kevin

Carey,

My usage of terms was way off.    Thanks for correcting the words.

Kevin

kevin Abel wrote:abstract class Vehicle { ... } class Car extends Vehicle { ... } class Bus extends Vehicle { ... } class Motorcycle extends Vehicle { ... }Is there a way to show interface and implements in this style?

Here's a scanner that will extract those from all .java files in a given directory tree.
import java.io.File; import java.io.FileNotFoundException; import java.util.Scanner; import java.util.Set; import java.util.TreeSet; import java.util.regex.Matcher; import java.util.regex.Pattern; public class GrepJavaClasses { private static final File DIR = new File( "F:/_srcjava2" ); // EDIT FOR YOUR SITUATION private static final Pattern PAT = Pattern.compile( "(enum|interface|class|abstract\\s+class)\\s+" + "([a-zA-Z_][a-zA-Z0-9_]*)" + "(\\s+extends(\\s+[a-zA-Z_][a-zA-Z0-9_]*,?)+)?" + "(\\s+implements(\\s+[a-zA-Z_][a-zA-Z0-9_]*,?)+)?" ); public static void main( String[] args ) { walk( DIR ); } static void walk( File file ) { if( file.isDirectory() ) { File[] files = file.listFiles(); if( files != null ) for( File f : files ) walk( f ); } else if( file.isFile() && file.getName().endsWith( ".java" ) ) { process( file ); } } static void process( File file ) { try( Scanner in = new Scanner( file ) ) { String name = file.getName(); Set<String> found = new TreeSet<>(); StringBuilder sb = new StringBuilder(); while( in.hasNextLine() ) sb.append( in.nextLine() ).append(' '); String s = sb.toString(); int start = 0; Matcher m = PAT.matcher( s ); while( m.find( start ) ) { found.add( m.group().replaceAll( "\\s+", " " ) ); start = m.end(); } for( String ss : found ) System.out.printf( "%-30s: %s {...}%n", name, ss ); } catch( FileNotFoundException e ) { System.out.println( e ); } } }
EDIT:
I've made some improvements to this so it will find things like
class NestableEventsList<E> extends TransformedList<E, E> {...}Not wanting to hijack this thread I'm not going to post it. If you are interested let me know and I'll start a new thread.

kevin Abel wrote:abstract classes
You cannot instantiate them.   myObj = new someAbstractclass;  wont compile.
Abstract classes can have some or all of the methods be Abstract.
Another class extends the abstract class.  The  methods that have code between the squiggle brackets are inherited and can be used as is or they can be overwritten.
The abstract methods have to be overwritten and given a body with code between its squiggle brackets.

interface
These can not be instantiated either.
None of the methods can have a body.
one or more interfaces can be implemented in a different class
Each method has to be overwritten or the compiler will complain.
Interfaces are a contract.  The classes that uses them must give a body to each of the methods.

Unfortunately all of this just tells you how to use them. It's sort of like reading how to use and maintain a lawnmower, when you just immigrated from Somalia and have no idea why you would want to use one.

kevin Abel wrote:. . . Can a class without the word abstract be inherited by the subclass?

Thanks,

Kevin

That question shows you are confused about nomenclature. You cannot inherit a class, but only its members. Non‑private mmbers of a class are implicitly inherited by its subclasses. You can subclass a class if it isn't labelled final and has an accessible constructor. Private constructors are not accessible to other code. Constructors don't count as members and aren't inherited by sybtypes.

Is there a way to show interface and implements in this style?  

interface List<E> {   // ... }class ArrayList<E> implements List<E> {   // ... }class LinkedList<E> implements List<E> {   // ... }This is a simplified version of this and this.

i think it's a good time for you to try making a GUI app with java swing and see what you can learn from that. extend the jframe class, use implements ActionListener for buttons, lots of real world use for the concepts.

also since you are learning about subclasses you need to learn about super keyword too. java compiler automatically adds it so you may never have needed to use it before.
eventually you run into a situation where you do need to use it yourself.

Note: If a constructor does not explicitly invoke a superclass constructor, the Java compiler automatically inserts a call to the no-argument constructor of the superclass. If the super class does not have a no-argument constructor, you will get a compile-time error. Object does have such a constructor, so if Object is the only superclass, there is no problem.

If a subclass constructor invokes a constructor of its superclass, either explicitly or implicitly, you might think that there will be a whole chain of constructors called, all the way back to the constructor of Object. In fact, this is the case. It is called constructor chaining, and you need to be aware of it when there is a long line of class descent.

Java Superclass

S Fox wrote:i think it's a good time for you to try making a GUI app with java swing and see what you can learn from that.

While I agree with you that Swing stretches ones' understanding regarding interfaces and abstract classes, I think it is too complex a subject for an early beginner to start  with.

Carey Brown wrote:Here's a scanner that will extract those from all .java files in a given directory tree.

I've made some improvements to this so it will find things like
class NestableEventsList<E> extends TransformedList<E, E> {...}Not wanting to hijack this thread I'm not going to post it. If you are interested let me know and I'll start a new thread.

kevin Abel wrote:. . . Can a class without the word abstract be inherited by the subclass?

Thanks,

Kevin

That question shows you are confused about nomenclature. You cannot inherit a class, but only its members. Non‑private mmbers of a class are implicitly inherited by its subclasses. You can subclass a class if it isn't labelled final and has an accessible constructor. Private constructors are not accessible to other code. Constructors don't count as members and aren't inherited by sybtypes.

Is there a way to show interface and implements in this style?  

interface List<E> {   // ... }class ArrayList<E> implements List<E> {   // ... }class LinkedList<E> implements List<E> {   // ... }This is a simplified version of this and this.

There are also nested classes:
"A nested class is a member of its enclosing class. Non-static nested classes (inner classes) have access to other members of the enclosing class, even if they are declared private."