Week 5 — Relationships, Abstraction, and Inheritance (Java) — Comprehensive Notes Summary & Study Notes

📘 Relationships: Association, Aggregation, Composition

Association is the most general relationship: it describes that two classes communicate or interact. It is typically shown as a straight line (possibly with an arrow to indicate direction). Associations indicate that objects of one class hold references to objects of another class or call their methods.

Example: A Professor and Student class where a professor may call methods on students (e.g., assignGrade(Student s, ...)).

Aggregation models a has-a relationship where an object owns a collection or group of other objects but those parts can exist independently of the owner. Aggregation is often implemented as a data field in the aggregating class.

• Key idea: weak ownership — the part can outlive the whole.
• Examples: Professor has many Students; Hotel has many Suites; Truck has many Wheels.

Representation (Java): public class Student { private Name name; private Address address; // aggregation: Address may exist independently }

Composition is a stronger form of aggregation: a strong has-a relationship where the child depends on the parent and cannot exist separately. If the parent is destroyed, the children are too.

• Key idea: strong ownership — lifecycle of parts tied to the whole.
• Examples: Room has-a Door (in a model where doors are not reused), Car has-a Wheel (if modeled so wheels don't exist independently).

UML note: composition is often shown with a filled diamond on the owner side, while aggregation is shown with an open diamond.

When to use which: use aggregation when the contained objects make sense independently; use composition when the contained objects are conceptually part of the whole and have no meaning outside it.

🧬 Inheritance: The is-a Relationship

Inheritance expresses specialization: a subclass inherits characteristics (fields and methods) from a superclass. A subclass can be treated as an instance of its parent type (polymorphism).

• Examples: Motorcycle is-a Vehicle; Car is-a Vehicle.

Design questions to consider:

• Can every class be inherited? (Not necessarily — e.g., classes declared final can't be extended.)
• Can a class inherit from more than one class in Java? (No — Java doesn't allow multiple class inheritance.)
• Where can super appear? (super can be used in constructors and methods of a subclass to refer to the superclass members.)
• Must you call the superclass constructor? (Java implicitly calls the no-arg superclass constructor if you don't explicitly call super(...); if no no-arg exists, you must call an appropriate super.)
• How to prevent a method from being overridden? (Declare it final.)

🔁 Overloading vs Overriding

Overloading: same method name, different signature (parameter types/count). Occurs at compile-time (static binding). Constructors can be overloaded.

Overriding: subclass provides a new implementation for an inherited method with the same name and signature. Occurs at run-time (dynamic binding / polymorphism).

Notes:

• Constructors cannot be overridden (constructors are not inherited). Constructor chaining uses this(...) to call another constructor in the same class and super(...) to call a superclass constructor.
• static methods are bound at compile time and are not polymorphic in the same way as instance methods.

🧾 Abstract Classes and Abstract Methods

Abstract class: a class declared with the abstract keyword. It can contain concrete (implemented) methods and abstract methods (no body). You cannot instantiate an abstract class directly — it serves as a template for subclasses.

public abstract class Algonquin { // common attributes or concrete methods }

Abstract method: declared with abstract and no body; ends with a semicolon.

public abstract double getCircumference(); // no body

Rules and effects:

• If a class contains any abstract method, the class must be declared abstract.
• An abstract class may contain zero or more abstract methods.
• A concrete subclass must implement all inherited abstract methods, otherwise it must itself be declared abstract.
• Abstract methods define a contract: they force subclasses to provide specific behavior.
• Constructors and static methods cannot be abstract.

Use cases:

• When a behavior is conceptually required but the actual implementation varies by subclass (e.g., earnings() for different employee types). The superclass declares the abstract method and concrete subclasses implement it.

Design patterns and practices:

• Use abstract superclasses when you want to share common code and force specific methods to be implemented by subclasses.
• Many client codes are written to depend only on abstract superclass types, improving flexibility: methods can accept an abstract type parameter and operate on any concrete subclass.

🧱 Class Abstraction & Encapsulation

Class abstraction separates the implementation of a class from its use. The class author provides a description of how the class should be used (the interface), and hides implementation details.

Encapsulation bundles data (fields) and methods that operate on the data while restricting direct access to some of the object's components, typically using access modifiers.

Benefits: reduces coupling, allows internal changes without affecting clients, and enforces invariants.

🔐 Access Modifiers (Visibility and Inheritance)

Java provides several access levels for members:

• public: visible everywhere. Public members are inherited.
• protected: visible to classes in the same package and to subclasses (even if the subclass is in another package). Useful for members intended for use by subclasses.
• default (package-private): visible to classes in the same package only.
• private: visible only within the declaring class. Private members are not visible to outside classes and are not inherited.

Constructors in abstract classes:

• Abstract classes can have constructors. These are typically protected to prevent direct instantiation while allowing subclasses to call super(...) to initialize the inherited portion of state.
• Using protected for an abstract class constructor is good practice because constructors are meant to return new instances; making them public on an abstract class is misleading.

Access summary (class / package / subclass / global):

• public: yes / yes / yes / yes
• protected: yes / yes / yes / no
• (none): yes / yes / no / no
• private: yes / no / no / no

✅ Practical Examples & Clarifications

Example: abstract earnings()

• If earnings() makes no sense at the general level (e.g., Employee), declare it abstract in Employee and force SalariedEmployee, HourlyEmployee, etc., to implement it.

What happens if you try to instantiate an abstract class?

• Compilation error. You cannot create objects of abstract classes.

What if a class is not declared abstract but declares (or inherits) an abstract method?

• Compilation error. The class must be declared abstract unless it implements all abstract methods.

Polymorphism using abstract types:

• You can declare variables of an abstract superclass type and assign instances of concrete subclasses to them. This enables polymorphic method calls at runtime.

⚠️ Common Pitfalls and Best Practices

• Don’t confuse aggregation with composition; think about the lifecycle and independence of parts.
• Use final to prevent overriding when necessary.
• Prefer protected constructors in abstract classes to clarify intent while enabling subclasses to initialize state.
• Overloading vs overriding: remember which is compile-time vs run-time.
• Abstract classes are useful to factor shared code and specify required behaviors, but avoid forcing deep hierarchies unless the domain warrants them.

🧩 Summary (Key Takeaways)

• Association describes general links between classes; aggregation is weak ownership; composition is strong ownership.
• Inheritance models is-a relationships and enables polymorphism.
• Overloading = compile-time (same name, different signature); Overriding = run-time (same signature, subclass provides implementation).
• Abstract classes/methods define contracts and partial implementations; concrete subclasses must implement abstract methods to be instantiable.
• Access modifiers control visibility and inheritance; choose protected for intended subclass access and encapsulate other members appropriately.

(Reference: Liang D. Y., Introduction to Java Programming — slides Week #5)

✍️ Notes from Instruction / User Input

This section captures the instruction for these notes: produce a comprehensive summary of the key concepts from the provided slides, include examples where helpful, and avoid oversimplifying. The notes above follow these instructions by describing relationships (association, aggregation, composition), inheritance and polymorphism, distinctions between overloading and overriding, abstract classes and methods, class abstraction/encapsulation, access modifiers, and practical examples and pitfalls.

Purpose: to provide a concise but thorough reference that a student can use to review Week #5 material and to reason about designing Java class hierarchies and access semantics.

How these notes were compiled: the primary source is the Week #5 lecture slides; the instruction here guided presentation style (headings with emoji, bolded key terms, short paragraphs, and example snippets where clarifying).