Object-Oriented Programming

Disciplines
Software Engineering
Object-Oriented Programming
Java
Architecture
Author

Marcos M. Raimundo

Published

July 23, 2026

This course explores the foundations of Object-Oriented Programming (OOP) through a rigorous software engineering and memory management lens. Students will learn how to design, connect, and scale objects, treating each class not merely as a data structure, but as a robust state machine with explicit behavioral contracts, memory lifecycle rules, and quantifiable coupling metrics.

Final Objectives

The goal is to provide a deep understanding of how object-oriented systems are designed, validated, and maintained. By the end of this course, students will be able to bridge syntax concepts like classes, inheritance, and interfaces with their theoretical architectural roots, including the Single Responsibility Principle, the Liskov Substitution Principle, invariant protection, and structural design patterns.

Course Content

Click on each lesson to access its detailed planning and study materials.

Part 1: Foundations of State and the Isolated Object

  • Lesson 1: The Object-Oriented Paradigm and the Java Machine
    • OOP Concept: The Java ecosystem (JVM, Bytecode, JIT), Stack vs. Heap memory, garbage collection and reachability, and the anatomical structure of a class (attributes, constructors, accessors, public interface vs. private implementation).
    • Design Concept: Abstracting the real world into state, behavior and identity; the physical difference between the class (the blueprint) and the object (the instance in memory); encapsulation as an engineering strategy (Information Hiding), not a security feature; the mechanics of parameter passing (primitives vs. references).
    • Objectives: Understand the physical constraints of the execution environment, how to translate real-world entities into code blueprints, and why every design choice in this lesson traces back to keeping the cost of change low (the TRUE acronym).
    • Expected Competencies: Ability to define a class, instantiate objects in the Heap, explain why an object’s state must stay private, and predict the outcome of passing a primitive vs. an object reference into a method.
  • Lesson 2: The Object as a Finite State Machine
    • OOP Concept: The anemic domain model anti-pattern; Command-Query Separation (CQS); Design by Contract (pre/post-conditions); the standard exception kit (IllegalArgumentException, IllegalStateException, NullPointerException); the equals()/hashCode() contract.
    • Design Concept: The object as a Deterministic Finite Automaton — attributes as state, methods as the only authorized transitions. Class invariants as the generalization of loop invariants. The constructor as the inductive base of a proof of validity; Fail-Fast to prevent “zombie objects”.
    • Objectives: Treat encapsulation not as a security feature, but as the mechanism that keeps a state machine inside its valid region, and treat the constructor as mathematically different from every other method.
    • Expected Competencies: Ability to design strict, Fail-Fast constructors, separate commands from queries, write methods with explicit pre/post-conditions, and correctly override equals()/hashCode() together.
  • Lesson 3: Composing Systems — Contracts and Stability
    • OOP Concept: Collaborating specialist objects (Produto/ItemCarrinho/Carrinho); the Interface vs. Implementation boundary; the Law of Demeter; programming to interfaces for Plug-and-Play extensibility.
    • Design Concept: Moving from the anatomy of a single object to the architecture of a system of objects; low coupling through delegation instead of “intimate” knowledge of a collaborator’s internals; Tell, Don’t Ask as the technical cure for “train wreck” code chains.
    • Objectives: Recognize a system as a network of specialists communicating through stable contracts, not a pile of classes exposing their data to each other.
    • Expected Competencies: Ability to design low-coupling collaborations, diagnose Law-of-Demeter violations, and program against an interface so new implementations plug in without recompiling existing code.

Part 2: Composition and Contracts (Connecting Objects)

  • Lesson 4: Decomposition and Responsibility
    • OOP Concept: The three association types — Dependency (“uses-a”), Aggregation (“has-a”), and Composition (“is-part-of”); Dependency Injection via constructor.
    • Design Concept: The Single Responsibility Principle (SRP) and the “AND test” for diagnosing God Classes; cohesion and coupling as the two quality metrics; Robert Martin’s Actor theory and the LCOM metric; the opposite failure modes of over-fragmentation (Shotgun Surgery) and the Anemic Domain Model; Delegation as the mechanism that makes composition as powerful as inheritance.
    • Objectives: Learn to decompose a God Class into small, specialized, highly cohesive units — without swinging to the opposite extreme of fragmenting a domain concept into meaningless pieces.
    • Expected Competencies: Ability to diagnose SRP violations with the “AND test”, choose the correct association type for a relationship, and refactor tangled responsibilities into an orchestrator that delegates to injected specialists.
  • Lesson 5: Coupling and Contracts
    • OOP Concept: Quantitative and qualitative coupling metrics — CBO (Coupling Between Object Classes) and the Myers coupling scale (Content, Common, Stamp, Data); the GRASP Information Expert pattern; the Dependency Inversion Principle (DIP).
    • Design Concept: Why passing a dependency through the constructor does not, by itself, guarantee logical decoupling — Feature Envy as the classic counter-example; why coupling to concrete classes eventually caps what composition alone can achieve, and how inverting the dependency onto an abstraction breaks that ceiling.
    • Objectives: Move from intuition (“this feels coupled”) to measurement and diagnosis, and recognize the point where composition needs an abstraction to keep growing safely.
    • Expected Competencies: Ability to diagnose Feature Envy, reason about a class’s CBO, classify a dependency on the Myers scale, assign responsibility via Information Expert, and invert a dependency onto an interface to satisfy the Open/Closed Principle.
  • Lesson 6: Interfaces and the Contract of Behavior
    • OOP Concept: Interfaces as pure behavioral contracts; modern interfaces (default/static/private methods) and the “Blind Mutator” pattern; exceptions as the enforcers of business rules the type system cannot express.
    • Design Concept: An interface says what an object does, never what it is or how; the boundary between an interface and an abstract class is state, not behavior; a type is defined by the messages an object answers, not by what it stores.
    • Objectives: Treat interfaces as behavioral promises the compiler enforces, and exceptions as the runtime enforcement of promises the compiler cannot check.
    • Expected Competencies: Ability to design a pure interface, use default/static/private methods without breaking the interface’s statelessness, choose between an interface and an abstract class, and guard a contract’s business rules with Fail-Fast exceptions.

Part 3: Abstraction and Polymorphism (Cautious Reuse)

  • Lesson 7: Polymorphism, Binding, and Generics
    • OOP Concept: Late Binding (Dynamic Dispatch); the Cardelli–Wegner taxonomy of polymorphism (Universal: Inclusion and Parametric; Ad-hoc: Overloading and Coercion); Generics as a compile-time safety net for collections.
    • Design Concept: The compiler only checks that a method exists on the declared type; the JVM decides, at runtime, which implementation actually runs — the mechanism that makes the Open/Closed Principle achievable in practice, ending “type if chains” for good.
    • Objectives: Distinguish polymorphism that truly decouples (Inclusion) from polymorphism that merely organizes syntax (Overloading), and see Generics as parametric polymorphism in action.
    • Expected Competencies: Ability to explain Late Binding, classify a given polymorphism instance in the Cardelli–Wegner taxonomy, refactor a type-if chain into polymorphic dispatch, and use Generics to move a type error from runtime to compile time.
  • Lesson 8: Inheritance — DNA, Fragility, and Template Method
    • OOP Concept: extends mechanics and state inheritance as physical incorporation; the Fragile Base Class problem; abstract classes as a “semi-finished machine”; the Template Method pattern.
    • Design Concept: Inheritance defines what an object is (the strongest coupling in OOP), not just what it does; a legitimate specialization needs shared DNA and the need for polymorphic treatment — reuse alone is not a reason to inherit; invisible invariants (ordering assumptions, return semantics, a skipped super call) are what make base classes fragile.
    • Objectives: Recognize when inheritance is the right tool versus when composition should be used instead, and see the base class as the guardian of an algorithm’s structure via Template Method.
    • Expected Competencies: Ability to diagnose a Fragile Base Class scenario, decide between inheritance and composition for a given relationship, design an abstract class with private state and protected hooks, and write a Template Method with a locked skeleton.
  • Lesson 9: Breaking Contracts (Exceptions)
    • OOP Concept: The Throwable hierarchy, custom exceptions, and try-with-resources.
    • Design Concept: Design by Contract. Distinguishing unrecoverable programming bugs (Unchecked) from expected business rule exceptions (Checked). The critical difference between GC memory management and deterministic physical resource management.
    • Objectives: Establish robust error-handling policies and avoid using exceptions for standard control flow.
    • Expected Competencies: Ability to design a semantic exception hierarchy and ensure deterministic release of OS resources (files, sockets).

Part 4: Patterns and Architecture (Consolidation)

  • Lesson 10: Creational and Structural Patterns
    • OOP Concept: Factory Method, Builder, and Adapter patterns.
    • Design Concept: Encapsulating complex instantiation to preserve invariants globally. Structurally harmonizing incompatible contracts without breaking encapsulation.
    • Objectives: Remove the responsibility of the new keyword from the core business logic.
    • Expected Competencies: Ability to implement Builders for complex objects and Adapters to integrate legacy or third-party code cleanly.
  • Lesson 11: Behavioral Patterns
    • OOP Concept: Strategy and Observer patterns.
    • Design Concept: Achieving the Open/Closed Principle (OCP) via composition — extending behavior without modifying source code. Decoupling internal communication through event-driven state synchronization.
    • Objectives: Consolidate the lessons of Parts 2 and 3 into dynamic, interchangeable algorithms.
    • Expected Competencies: Ability to swap business rules at runtime using Strategy and broadcast state changes using Observers.
  • Lesson 12: Architectural Pattern — MVC
    • OOP Concept: Model-View-Controller (MVC).
    • Design Concept: Architectural separation of concerns. Orchestrating interfaces, observers, and domain logic into a fully decoupled system where the Model never inherently knows the View.
    • Objectives: Close the course by tying all isolated object concepts into a macro-architectural design.
    • Expected Competencies: Ability to structure an application dividing interface logic from pure business rules, applying Observer for reactivity.

References

  • Weisfeld, M. The Object-Oriented Thought Process. 5th ed. Pearson Education.
  • Bloch, J. Effective Java. 3rd ed. Addison-Wesley Professional.
  • Metz, S. Practical Object-Oriented Design in Ruby: An Agile Primer. Pearson Education.
  • Arnold, K., Gosling, J. & Holmes, D. The Java Programming Language. 4th ed. Addison-Wesley.
  • Eckel, B. Thinking in Java. 4th ed. Prentice Hall Professional.