Tomski Simon

Ikpefua Jacob-Obinyan wrote: the yield() method "tends" to make the currently running thread head back to a runnable state to allow other threads of the SAME priority get a turn.

I think both of us are right:) Threads of the same and higher priority will be allowed to run. Below you can find quote from "Java Thread Programming" - Paul Hyde (Chapter 6 - Voluntarily Relinquishing the Processor: Thread.yield()):

To help ensure that other threads in the VM get a turn to run on the processor, a thread can voluntarily give up its turn early. If a thread invokes the static method Thread.yield(), the thread scheduler will swap it off the processor and allow another thread to run. It is likely (but not guaranteed) that only threads having a priority equal to or greater than the one that yielded control will be considered by the thread scheduler.

Yours changes will not have impact on program output because:
1. Following condition never will be true:
if (i%5 != 0) { ++i; }
because each new thread will start with i value that can be divided by 5

2. Following code:
Thread.yield()
means that current thread should stop working for a while and check if there are any other threads with higher priority to run. So no matter if thread will be interrupted or not work must be done from beginning to the end.

So no matter if you leave or remove above parts of code your output will not change.

You can set Car colour in the main method and once when your Car object is ready you can pass it to the Driver constructor.

I found quite easy explanation (written by Mario Peshev) of each term:

Loose coupling: your classes must be independent from each other. Otherwise
your class could 'break' because of another 6,7... 10 classes that are
strongly related to it. With better coupling your class doesn't need many
other classes and your application is bit stronger.

High Cohesion - that's the entity of a class or method. You shouldn't
develop a method that acts like a whole big application (for example, all of
your program in a method). When an exception comes out, it's harder to find
the problem and look over thousands of lines code. When you keep strong
cohesion, your methods act like 1 simple organism and it's easier to look
over them.

Strong cohesion: System.out.println(message);
Simple operation, gets the information and send it to the console.

Bad cohesion: a method that executes connecting to Internet, downloading
information, putting it into a database, changing details, exporting,
printing, uploading back to Internet. All of this activities in a method.
How many errors could occur here? ;)

Encapsulation, in my opinion, is strongly related to data abstraction. They
both form a mechanism like a Black Box (airplanes` black boxes) or a clock -
you just see the display, but you don't have an idea what's hidden inside
and how it works. And you don't care. All data and operations are collected
in your class. Good practise is hiding the details: all fields private and
usage of getters and setters to gain access to your fields. That's how you
can implement complex logic in your getters/setters, you can restrict access
(read-only, write-only or both, or none). Finally, you show users only the
information that he/she needs. Remember the example with the clock- you
don't mind if the mechanism gets replaced, if you see this display, working
the same way.
Make private fields, public/protected getters and setters; private methods
for internal algorithms that are no interest for the user; public methods
that user can use. If you update your app and change your logic, it should
be invisible for the user- he just have to use the same algorithm and a set
of operations.

Source: http://java.ittoolbox.com/groups/technical-functional/java-l/tight-encapsulation-loose-coupling-and-high-cohesion-in-classes-1089364

To achieve loosely coupling you need to make both classes independent from each other (as much as possible). Mike's example is a good one. I would even create some Vehicle interface that would be passed to the Driver constructor instead of Car type. In such case we can pass not only a Car object but any object that implements such interface.

You didn't reinitialised your final variable. You have two independent class fields with the same name "c" C.c and B.c. What happen in your main method is a polymorphism, which only can be applied for methods (not for fields).

So you have the same method name for both classes C.as() and B.as(). We know that B class inherits from C. You create B object that will be stored in C variable and then you want to execute as() method (C.as()). Thanks to polymorphism java knows that C stores object of the type B and will execute as() from B object instead of C.as() method.

How I mentioned before polymorphism is applied only for method, so when you try to access your c field explicitly (not through method) then no matter what type of object is stored in C variable it will always access its own C.c field.

The best will be if you change your B.as() method to:
class B extends C { public void as(){System.out.println("I'm B type object");} public final int c=70; B() { } }


So in this example you can see that it was just coincidence that method as() was returning value of the c field.

If you change
System.out.println(InEn.A);
to
System.out.println(InEn.B);
you will understand why there is a null in the first line of your output.

It looks like constructor is executed for each constant (A, B, C, D) of your enum. So it is not possible to print value of A constant before it is created.

About lack of inheritance for enums in java: https://coderanch.com/t/327915/java/java/Enum-Type-inhteritance