D.1.2 Distinguish between an object (definition, template or class) and instantiation

The process of creating an instance of an object from a class is called instantiation.  

The class is an abstract representation of an object. It is the blueprint (template) of an object that defines its actions and properties. 

In OOP, instantiation is done by using a particular method called a constructor. The constructor is a method with the same name as the class.

Look at the code below to see an example of a constructor. Examples of these can be seen in the Student class above.

public class Student {
   String name;
   int age;
   int grade;


//Constructor
public Student (String newName, int newAge, int newGrade) {
   name = newName;
   age = newAge;
   grade = newGrade;
   }
}

There are three steps when  creating an object from the class:

• Declaration: 
  • a variable declaration with a variable name with and object type
• Instantiation
  • the “new” keyword is used
• Initialisation
  • the “new” keyword calls the constructor to initialise the new object. 

A new student can be instantiated with the following code:

Student s1 = new Student(Toni, 17, 75);

The new student is now instantiated in a physical memory location. It is important to note that the variable s1 does not hold the object but only refers to the object in a memory location. This concept of how object references work is covered in more detail in D.4.5. 

It is also worth noting that every class has a constructor. Even if one is not explicitly written the JAVA compiler builds a default constructor for the class. For example for a simple class such as:

public class Student {
   String name;
   int age;
   int grade;
}

We can instantiate a student with the following code. 

Student s2 = new Student();

This will create a default student. To define the state of that student we could code the following. 

s2.name = "Molly";
s2.age = 16;
s2.grade = 86;

D.1.7 Reducing dependencies

Why Reduce Dependencies?  

Keeping Your Code Tidy and Flexible

Imagine building a house of cards. Each card leans on others for support. If you pull out one card carelessly, the whole structure might collapse!  This is similar to what can happen in software when parts of your code are too tightly connected, or highly dependent on each other.

The Problem with connected code

High dependency creates a web of connections within your code. This can lead to several headaches:

• The Ripple Effect: Changing one part of your code can unexpectedly break other seemingly unrelated parts. This makes updates and bug fixes a nightmare.   
• Code Reusability Takes a Hit: When parts are tightly interwoven, it's difficult to reuse them in other projects or even in different parts of the same project. Imagine trying to reuse a room from your house of cards in a different structure!
• Maintenance Mayhem: The more dependencies you have, the harder it is to understand, debug, and maintain your code. It's like trying to untangle a giant ball of yarn.
• Testing Troubles: Testing becomes more complex as you need to consider how changes in one part affect all its dependents.

Example

You have a program that calculates taxes.  It depends directly on a specific tax law calculation module.  But tax laws change frequently! Every time the law changes, you have to modify your main program. This is a high dependency.

Now, imagine you introduce an interface called "TaxCalculator". Your main program now depends on this interface, not the specific tax law module. Different modules can implement the "TaxCalculator" interface for different tax laws.

 When the law changes, you simply plug in a new module. This is low dependency.   

Benefits of Reducing Dependencies

• Increased Flexibility: Easily adapt to changes and add new features without causing widespread breakage.
• Improved Code Reusability: Reuse components in different contexts, saving time and effort.   
• Simplified Maintenance: Understand, debug, and maintain code more easily.
• Enhanced Testability: Test individual components in isolation, making testing more effective.   

In essence, reducing dependencies helps you create code that is:

• Modular: You can easily assemble and rearrange components like building with Lego blocks.
• Robust: Less prone to breaking when changes are made.
• Maintainable: Easier to understand and update over time.

By striving for low dependency, you're building a more stable and adaptable software foundation for the future.

How to Reduce Dependencies

1. Interfaces:  Promises, Not Implementations

Think of an interface like a contract. It defines a set of methods a class must provide but doesn't specify how those methods should be implemented. This is powerful because it allows different classes to fulfil the same contract in their way.

How this reduces dependency:

• Abstraction: Instead of depending on a concrete class, your code depends on the interface. This means you can swap out different implementations without affecting other parts of your code.
• Loose Coupling: Classes are less tightly connected, making changing one without impacting others easier.

Example:

Imagine an Authentication interface with a login() method. You could have different classes like GoogleAuth, FacebookAuth, and EmailAuth, each implementing this interface. Your application can then work with the Authentication interface without knowing the specific authentication method being used.

// 1. Interfaces Example: Authentication

interface Authentication {
  boolean login(String username, String password);
}

class GoogleAuth implements Authentication {
  @Override
  public boolean login(String username, String password) {
    // Logic to authenticate with Google
    return true; // Or false if authentication fails
  }
}

class FacebookAuth implements Authentication {
  @Override
  public boolean login(String username, String password) {
    // Logic to authenticate with Facebook
    return true; // Or false if authentication fails
  }
}

// Usage:
Authentication auth = new GoogleAuth(); // Or new FacebookAuth();
if (auth.login("user", "password")) {
  // Authentication successful
}

2. Abstract Classes: A Middle Ground

Abstract classes are a hybrid between interfaces and concrete classes. They can have both abstract methods (no implementation) and concrete methods (with implementation). This allows you to define some common behaviour while still leaving room for specialization.

How this reduces dependency:

• Partial Implementation: Provides a base implementation that subclasses can inherit, reducing code duplication.
• Flexibility: Allows subclasses to customize behaviour while still adhering to a common structure.

Example:

A Shape class could be abstract, with an abstract method calculateArea(). Subclasses like Circle and Rectangle would then provide concrete implementations for calculateArea().

// 2. Abstract Classes Example: Shape

abstract class Shape {
  abstract double calculateArea();
}

class Circle extends Shape {
  double radius;

  @Override
  double calculateArea() {
    return Math.PI * radius * radius;   

  }
}

class Rectangle extends Shape {
  double width;
  double height;   


  @Override
  double calculateArea() {
    return width * height;
  }
}

// Usage:
Shape circle = new Circle();
Shape rectangle = new Rectangle();

3. Design Patterns: Tried and True Solutions

Design patterns are reusable solutions to common software design problems. Many patterns specifically address dependency management.

How this reduces dependency:

• Decoupling: Patterns like Strategy, Factory, and Observer help decouple objects and reduce dependencies.
• Flexibility: Make it easier to change and adapt your code without affecting other parts.

Example:

The Strategy pattern encapsulates different algorithms (like sorting algorithms) and allows them to be used interchangeably. This reduces the dependency between the client code and the specific algorithm.

// 3. Design Patterns Example: Strategy (simplified)

interface SortingStrategy {
  void sort(int[] array);
}

class BubbleSort implements SortingStrategy {
  @Override
  public void sort(int[]   
 array) {
    // Bubble sort implementation
  }
}

class QuickSort implements SortingStrategy {
  @Override
  public void sort(int[] array) {
    // Quick sort implementation
  }
}

class Sorter {
  private SortingStrategy strategy;

  public Sorter(SortingStrategy strategy) {
    this.strategy = strategy;
  }

  public void sort(int[] array) {
    strategy.sort(array);   

  }
}

// Usage:
Sorter bubbleSorter = new Sorter(new BubbleSort());
Sorter quickSorter = new Sorter(new QuickSort());

In Summary

These techniques aim to create more modular, flexible, and maintainable code by:

• Reducing direct dependencies between concrete classes.
• Promoting abstraction and loose coupling.
• Encapsulating variability and allowing for easier changes.

By using these techniques effectively, you can make your code more robust and easier