Use Interface or Class when instancing? Why?

Now take this bit of code for example:

class Animal{
    void eat() {
        System.out.println("eating");
    }
}

class Cat extends Animal {
    void claw() {
        System.out.println("Clawing");
    }
}
public class Solution {
    public static void main(String[] args) throws Exception{
        Animal cat1 = new Cat();
        cat1.eat();
        //! cat1.claw(); // Error on this line because Animal class doesn't have a claw method

        Cat cat2 = new Cat();
        cat2.eat();
        cat2.claw();
    }
}

I commented out one line because the code will not compile with that line. This is because, as I mentioned in the first post, that the methods exposed (the ones you can use on an object) are specifically derived from the variable type. The 'cat1' variable is of type Animal, so it does not have the claw() method even though the object that is initialized is a Cat object. You can force the object type to be a Cat so you can call the claw() method, but it won't allow you without this step. Here is how you force:

((Cat)cat1).claw();

This works fine in this code, because its a contained example, but be aware that real world code is very abstract and it is best practice to check first that the object is of the type you want to force it to before forcing it to that type. If this wasn't a Cat object then that line would throw an error and the code would fail.

So, the answer is it depends? Because from what I can understand about loose coupling is that if we are very confident that no changes will be made, we should instantiate by the class itself, while if there is a potential for change we should instantiate by interface?

My first example, the printColleciton() method is a example of loosely coupled code. It can handle any class that has in its tree a class that extends the Collection class. Here is a list of the classes that extend Collection: AbstractCollection, AbstractList, AbstractQueue, AbstractSequentialList, AbstractSet, ArrayBlockingQueue, ArrayDeque, ArrayList, AttributeList, BeanContextServicesSupport, BeanContextSupport, ConcurrentHashMap.KeySetView, ConcurrentLinkedDeque, ConcurrentLinkedQueue, ConcurrentSkipListSet, CopyOnWriteArrayList, CopyOnWriteArraySet, DelayQueue, EnumSet, HashSet, JobStateReasons, LinkedBlockingDeque, LinkedBlockingQueue, LinkedHashSet, LinkedList, LinkedTransferQueue, PriorityBlockingQueue, PriorityQueue, RoleList, RoleUnresolvedList, Stack, SynchronousQueue, TreeSet, Vector I wouldn't need to change the method if I made changes to the code in main:

public static void main(String[] args) throws Exception {
   Vector<String> strings = new Vector<>();
   strings.add("one");
   strings.add("two");
   ConcurrentLinkedDeque<Integer> ints = new ConcurrentLinkedDeque<>();
   ints.add(1);
   ints.add(2);
   LinkedHashSet<Double> doubles = new LinkedHashSet<>();
   doubles.add(1.0);
   doubles.add(2.0);
   PriorityQueue<BigInteger> bigInts = new PriorityQueue<>();
   bigInts.add(new BigInteger("1"));
   bigInts.add(new BigInteger("2"));

   printColletion(strings);
   printColletion(ints);
   printColletion(doubles);
   printColletion(bigInts);
}

"So, the answer is it depends?" Almost every single answer to any question in programming can be answered with "it depends". You wont ever go wrong by using best practices no matter what your level, but when you start becoming a mid level to senior level programmer you can definitely go outside the bounds on those rules to come up with a better solution to the specific problem you're solving with your code.

Okay, this answer has lit up so many light bulbs in my head, so thank you for that! 😆 Especially this piece of code that you wrote:

static void printColletion(Collection a){
   for(var t : a) System.out.println(t);
}

Never even thought of this! But that doesn't explain ☹️: What are the practical cases where (say) I should instantiate an ArrayList like this:

List<Object> myList = new ArrayList<>();

or like this:

ArrayList<Object> myList = new ArrayList<>();

The type should be declared when instantiating when you know what will be held. For example if you want a list to hold Strings then don't use List<Object> as List<String> is better. Object would be used if you either 1- know that various different unrelated types are going to be stored or 2- you are not sure what types are going to be stored. Now the benefits of using List (or any abstract type) as opposed to a specific type like ArrayList: In this example first realize that there are different types of Lists with their strengths and weaknesses, this applies to any class. Lets say you write thousands of lines of code that only uses ArrayList, but then after learning more you find that a ArrayList for your specific problem is a very poor choice and that a Stack instead would provide better performance. Now you would have to go through ALL the lines of code and replace every place that had ArrayList<> with Stack<>. That could be very time consuming, checking all your classes and methods. Now if you had used List<> instead all you would have to do is change the line, or maybe few lines, where a new ArrayList<> is initiated and change those lines to new Stack<>. You wouldn't have to search every single method or other place where it just uses an already initialized ArrayList<>.

Thank you! Really appreciate it. Most forums just explain that "It's good practice" without actually telling why it is such. You clarified this.

Trust me, you will start to understand this with experience. It didn't make any sense to me when I first started doing it, but over the years and writing my own code, all these concepts started coming together. Check out my forum post. If you have some time watch the first video I linked and then the 2 about sorting algorithms. The first one is about an hour while the other 2 are about ~ 15 minutes a piece. The last one is 5 hours, and while it is REALLLY good, it isn't a beginner video. Feel free to try watching it, but you may need to come back to it in another 15 levels or so.

And what does 'var' mean in this code? (copied from above)

static void printCollection(Collection a){
   for(var t : a) System.out.println(t);
}

I've only seen this loop before with specific type definition, like this: for(String str : list) or for(Cat c : list) etc.

'var' is a java keyword that can be used in the place of variable type where the compiler will figure out the type at runtime. There are some restrictions, such as it can't be used for class fields or anything that is pre-loaded, but you can use it in your code:

class Cat {
    void meow() {
        System.out.println("MEOOOOWW");
    }
}
public class Solution {
    public static void main(String[] args) {
        var intVar = 10; // java makes this an int type
        System.out.println(intVar);

        var stringVar = "Something somethign"; // java makes this a String type
        // and you can use the String methods:
        System.out.println(stringVar.substring(5, 10));

        var cat = new Cat(); // java makes this a Cat type, which is a custom class
        // and you can use the Cat class methods
        cat.meow();
    }

}

It was added in Java 10, so can't be used on Codegym because they use Java 8.

Then not on the CodeGym site but elsewhere, but I will definitely use this one because I really like it.:)