Section 3 · Object-Oriented Design: Basic Concepts
On this page 11 headings
Learning goals: Identify objects, their state and behaviour; explain encapsulation and classes; recognise association, composition, inheritance and dependency.
Object-oriented thinking organises software around collaborating objects whose data and behaviour belong together.
Supermarket Journey: Find the Objects
Objects are the key building block; we imagine the working of software in terms of interacting objects, which usually represent tangible real-world entities.
Key objects when buying from a supermarket: products (bread, milk, shirt), the shopping cart, the order the cashier creates (a list of products and the total bill), and the payment (cash, credit card or debit card). In the same way, software objects represent real-world tangible entities. Thinking in objects encourages us to ask what information each object owns and what operations it should perform.
What Is Inside a Software Object?
An object bundles data and methods. Data stores the object's current properties, while methods are operations that work with the object's information or provide a useful service. A Product object, for example, could keep its name, type and price and provide add, edit, or delete operations in the simplified lecture model.
This organisation is often described as encapsulation. Data hiding means outsiders should not automatically be able to change every internal field. Instead, other objects use the operations the class intentionally makes available. Think of a safe room for state and a service counter for approved operations.
Encapsulation and Data Hiding
Encapsulation protects an object's internal representation behind a defined interface. In the illustration, Object B may send a normal request to Object A's public Methods counter; it should not reach straight into A's Private Data safe.
An advantage of decomposing a system into objects with data abstraction is that it divides the system into parts with high cohesion and low coupling: data variables and related methods are encapsulated together (high cohesion), and interaction between objects is minimised (low coupling).
Exam clue: A private field cannot be changed through unapproved access.
Product Object: Its Attributes and Operations
Product data members: name, type, size, colour, brand, about, manufacturer, dimensions, cost. Methods: add_product(), edit_product_details(), delete_product().
A useful distinction: attributes answer 'What does this product know about itself?' Methods answer 'What can this object's defined operations do?' The exact choices depend on the real application design; we should not infer payment processing or inventory updates from the Product example unless those responsibilities are explicitly assigned.
A Class Is the Blueprint, Objects Are Instances
A class is a template used to create objects. The Product class describes a common set of attributes and operations, while each instance supplies its own values. For example, electronic items, clothes and food items are all objects of type Product.
The objects are not separate subclasses merely because their values differ. They are instances of the same Product template in this illustration. The distinction matters: a class defines a type; an object is an actual entity of that type at runtime. Inheritance, discussed later, is a relationship between classes, not between a template and its instances.
Association: Seller Calls Inventory
Association represents a relationship in which objects know of or use one another. In the Seller Portal example, Seller asks Inventory for help through `view_inventory(seller_id)` and receives a stock result. The use is visible through a request and a response.
The picture is an intuitive object interaction. A formal UML class association is normally shown as a solid line, optionally with navigability information. The key point here is not ownership or inheritance: Seller needs Inventory to perform a task. Do not mistake ordinary cooperation for a whole–part relationship.
Composition: Catalogue Is Made of Products
Composition is a strong whole–part relationship in UML. The lecture illustrates it using a Catalogue that contains Products. In notation, the filled diamond sits at the whole end—Catalogue—and the line leads to the part—Product.
UML notation: The filled black diamond marks the whole, not the part.
Inheritance: Product and Specialised Kinds
Inheritance allows a specialised class to reuse and extend a more general class. In the example, Product is the parent class, with shared attributes such as name and cost. Electronics, Books, and Clothing are specialised kinds of Product; Books can add author and publisher, while Clothing can add size and colour.
The test is 'Is a kind of': a Book *is a kind of* Product. In UML generalisation, the hollow triangular arrowhead points toward the parent class, Product. It is different from composition, whose black diamond marks a whole. Students often mix up these two symbols; check both the meaning and the arrowhead when reading a diagram.
UML notation: Hollow triangle points to the superclass.
Dependency: Interface Change Affects Class B
Class B implements Interface A; if A changes, B has to be changed — common in languages like Java.
Recognize Class Relationships with Three Questions
Association — A delegates to B / A needs help from B. Composition/Aggregation — B is a part of A / A contains B / A is a collection of Bs.
Inheritance — A is a kind of B / A is a specialisation of B.
Communicating the design to other team members (and sometimes clients) is important — this is done by creating a model of the system, using UML.
Quick revision and self-check
Question: How are a class and an object different?
Answer: A class is a template/type; an object is one instance.
Question: Which relationship means “is a kind of”?
Answer: Inheritance/generalisation.
Question: Where does a composition diamond go?
Answer: At the whole/owner end.
Question: What protects private object state?
Answer: Encapsulation and access through defined operations.