Exam Practice

An instance of a class at a certain point in time, having state, behavior, and identity.

A blueprint or template used to create objects, defining attributes and operations.

The state or data of an object, for example name and age for a Person.

The behavior of an object, for example study() for a Student.

The property that distinguishes one object from another, even if their state is identical.

Combining data and operations together inside a boundary (usually a class) and protecting internal data from unnecessary outside access.

Restricting direct access to an object's fields, typically using private, so access is controlled through methods.

Showing important features while hiding unnecessary details, letting you focus on what an object does rather than how.

A mechanism allowing one class to acquire properties and behavior from another, creating an IS-A relationship.

The more general class that other classes inherit from, for example Animal.

The more specific class that inherits from a superclass, for example Dog extends Animal.

The relationship pointing from a specific concept toward a more general one, for example Dog to Animal.

The relationship pointing from a general concept toward a more specific one, for example Animal to Dog.

A class that cannot be instantiated directly. It may contain abstract methods that subclasses must implement.

A method declared without a body inside an abstract class, requiring a concrete subclass to provide the implementation.

A specification or contract describing what a class must be able to do, defined using the interface keyword.

A class that can be instantiated directly because all of its methods are fully implemented.

The ability of one thing to take many forms; a variable can refer to objects of different types.

A variable whose declared (supertype) type can hold objects of different subtypes at different times.

When a subclass provides a different implementation of a method inherited from its superclass, using the same signature.

Defining multiple methods with the same name but different parameter lists, resolved at compile time.

The process by which Java decides which overridden method to execute based on the actual object type at runtime.

The declared type of a variable, for example Animal in Animal animal = new Dog();.

The real type of the object a variable refers to at execution time, for example Dog in Animal animal = new Dog();.

A relationship representing that objects are connected and can interact, for example Student and Course.

A UML notation describing how many objects can participate in a relationship, such as 1, 0..1, *, 0..*, 1..*.

A whole-part relationship with weak ownership; the part can exist independently of the whole. Shown with a hollow diamond.

A whole-part relationship with strong ownership; the part's lifecycle depends on the whole. Shown with a filled diamond.

A relationship where one class uses another; changes in the used class may affect the dependent class.

A relationship where a class implements an interface, usually shown as a dashed arrow toward the interface.

How closely related the responsibilities inside a class are. Higher cohesion is generally better.

The level of dependency between objects or classes. Lower coupling is generally better.

The combination good OO design generally aims for, leading to code that is easier to understand, maintain, and modify.

A visual box divided into class name, attributes, and operations, representing a class and its structure.

Denotes public visibility in a UML class diagram.

Denotes private visibility in a UML class diagram.

Denotes protected visibility in a UML class diagram.

An acronym for five OO design principles: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.

A class should have one main responsibility, one reason to change.

Software entities should be open for extension but closed for modification.

A subtype object should be usable wherever its supertype object is expected, without breaking correctness.

A class should not be forced to depend on methods it does not need; prefer several small interfaces.

High-level and low-level components should both depend on abstractions, not on each other's concrete details.

Defines a class, the blueprint for creating objects.

Creates a new object instance.

Used to inherit from a superclass.

Used when a class provides the behavior required by an interface.

Marks a class or method as incomplete or too general to instantiate directly.

Defines a contract of required behavior that implementing classes must provide.

Restricts a member's access to inside its own class only.

Allows a member to be accessed from any other class.

Marks that a method is intentionally overriding a superclass method.

Restructuring existing code to improve its internal design, without changing its external behavior.

Problems caused by quick, messy, or poor coding decisions that make future changes harder.

A sign that code may have a deeper design problem. It does not always mean the code is broken.

Existing code inherited from another developer or older system, often hard to understand and undertested.

Move a block of related code out of a long method into a new, well-named method.

Remove an unnecessary method and place its code directly where it was called.

Split an overloaded class's responsibilities by moving related fields and methods into a new class.

Merge a nearly useless class's features into another class and remove it.

Relocate a method to the class it uses most, since that is where it truly belongs.

Relocate a field to the class that uses it most.

Replace a temporary variable that stores an expression's result with a method call.

Rename an unclear identifier to a meaningful name so the code explains itself.

Move a field shared by multiple subclasses up into their common superclass.

Move a field that only some subclasses need down into just those subclasses.

Move a duplicate method shared by subclasses up into the superclass.

Move a method that only some subclasses need down into just those subclasses.

Create an interface containing a common subset of methods that several clients need.

Replace an if/switch on a type code with a proper subclass hierarchy.

Extract a complex condition and its branches into small, clearly named methods.

Replace many related method parameters with a single object that groups them.

Replace type-checking switch/if logic with overridden methods on each subclass.

Replace an existing algorithm with a simpler or cleaner one that produces the same result.

Every piece of knowledge or logic should have a single, authoritative representation, avoid duplicating it.

Don't build functionality until it is actually needed, avoid speculative features.

Prefer the simplest solution or design that correctly solves the problem.

"Don't call us, we'll call you", an inversion of control where a framework or superclass calls into your code.

General Responsibility Assignment Software Patterns, a set of principles for deciding which class should have which responsibility.

Assign a responsibility to the class that already has the information needed to fulfill it.

Assign creation of B to class A when A aggregates, contains, or closely uses B.

Assign handling of a system event to a dedicated non-UI class representing the use case or system.

Assign responsibilities so dependencies between classes stay minimal.

Assign responsibilities so a class's tasks stay closely related and focused.

Assign behavior that varies by type to the types themselves via overriding, instead of conditionals.

Create an artificial class outside the problem domain purely to achieve low coupling and high cohesion.

Shield elements from variation elsewhere by wrapping the unstable point behind a stable interface.

A special method used to initialize a new object's state; shares the class name and has no return type.

The no-argument constructor Java automatically provides when a class defines no constructor of its own.

A reference to the current object instance, often used to disambiguate fields from parameters.

A reference used to call a superclass's constructor or an overridden superclass method.

A field or method that belongs to the class itself and is shared across all instances, rather than belonging to one object.

A visibility level accessible within the same package and by subclasses in other packages.

A visibility level, with no modifier written, accessible only to classes in the same package.

Methods that define logical equality between objects; they should be overridden together so hash-based collections behave correctly.

A method returning a human-readable string representation of an object, commonly overridden for debugging or display.

A property of an object whose state cannot change after construction, making it easier to reason about and share safely.

The general design principle of hiding implementation details from clients; encapsulation is the language mechanism used to achieve it.

A design pattern that encapsulates and centralizes object creation logic, decoupling clients from concrete constructors.

A Java feature providing type safety and reusable code that works across different types, checked at compile time.

A method's name together with its parameter types; it does not include the return type.