---
title: "Order total and subtotal() redesign"
subject: "Object Oriented Analysis and Design"
chapter: 3
key: "semester_6/object_oriented_analysis_and_design:order-subtotal-performance-redesign"
source: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/order-subtotal-performance-redesign
site: BCT Engineering
---

# Order total and subtotal() redesign

Object Oriented Analysis and Design · Chapter 3: Object Oriented Design

- Asked in: 2070 Bhadra, 8 marks
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/order-subtotal-performance-redesign
- Whole chapter: https://www.bctengineer.com/md/semester_6/object_oriented_analysis_and_design/chapter-3

## Question

Your manager reviews your design and codes of a sub-module that you have prepared, as depicted in the below figure. She suggests you to introduce subtotal( ) somewhere in your model thinking about the performance of the system.
[Figure: class Order with method total(), with a note attached: "for all my OrderLines ol, tot = tot + ol.getArticle().getPrice() * ol.getQuantity()"; Order is linked to class OrderLine with methods getQuantity() and getArticle(); OrderLine is linked to class Article with method getPrice().]
Modify your implementation and justify how does this update provides you better performance.

## Short answer

The original Order.total() loops over OrderLines, calling getArticle().getPrice() and getQuantity() per line, causing 3n messages and violating Law of Demeter. Adding subtotal() to OrderLine lets it compute price*quantity locally, reducing Order to n messages (subtotal) plus one getPrice per line, cutting messages from 3n to 2n, reducing coupling, and enabling caching.

## Answer

#### Present design and its problem
`Order.total()` loops over all its `OrderLine`s. For each line it calls `ol.getArticle()`, then `article.getPrice()`, and `ol.getQuantity()`, and then multiplies:

```text
 for each ol in orderLines:
     tot = tot + ol.getArticle().getPrice() * ol.getQuantity()
```
For n lines this makes **3n messages** from `Order`. `Order` also has to know about `Article`: it depends on two other classes and reaches through `OrderLine` to `Article`, which violates the Law of Demeter. If the objects are remote or loaded from a database, each call may be a network round trip or a query.

#### Modified design: add `subtotal()` to `OrderLine`
`OrderLine` already knows its quantity and its article, so by the **Information Expert** principle it should compute its own subtotal.

```text
 +---------+ 1   * +-----------+ *   1 +---------+
 | Order   |-------| OrderLine |-------| Article |
 |---------|       |-----------|       |---------|
 | total() |       | getQuantity()     | getPrice()
 +---------+       | getArticle()      +---------+
                   | subtotal()  <- new
                   +-----------+
```

```java
class OrderLine {
    private int quantity;
    private Article article;
    public double subtotal() {              // new method
        return article.getPrice() * quantity;
    }
}
class Order {
    private List<OrderLine> lines = new ArrayList<>();
    public double total() {
        double tot = 0;
        for (OrderLine ol : lines)
            tot += ol.subtotal();           // one message per line
        return tot;
    }
}
```

#### Why performance improves
1. **Fewer messages:** `Order` sends **n** messages (`subtotal`) instead of **3n**. The quantity is now read directly inside `OrderLine`, and only one message to `Article` (`getPrice`) remains per line, so the total falls from 3n to 2n messages.
2. **Fewer round trips in a distributed or persistent system:** `Order` makes one call per line instead of three, so there is less network and database traffic and less object loading.
3. **Lower coupling:** `Order` no longer depends on `Article`; it needs to know only `OrderLine`. A change in the price calculation (discount, tax) is made only in `subtotal()`.
4. **Easier caching and optimisation:** `OrderLine` can cache its subtotal, and `Order` can cache the total until a line changes. Each class manages its own data.
5. **Reuse:** the subtotal can be used by invoices and reports without repeating the formula.

In a single-process program the saving is small. The real gain is in distributed or database-backed systems, together with better cohesion and maintainability.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. Which class should get subtotal() and why?
   A. Article, because it has the price
   B. Order, because it has total()
   C. OrderLine, because it knows both quantity and article (Information Expert)
   D. A new Manager class
   Answer: C. OrderLine has the data needed, so Information Expert assigns subtotal() to it. (Key point: Where subtotal goes)

2. For n order lines, how many messages does Order send before and after the change?
   A. n before, 3n after
   B. 3n before, n after
   C. n before and after
   D. 3n before and after
   Answer: B. Before: getArticle, getPrice and getQuantity per line (3n); after: one subtotal() per line (n). (Key point: Message count)

3. How does the modified design affect coupling?
   A. Order depends on more classes
   B. Article depends on Order
   C. Order no longer depends on Article, only on OrderLine
   D. Coupling is unchanged
   Answer: C. The price calculation moves into OrderLine, removing Order's reach through to Article. (Key point: Coupling)

4. What else does subtotal() make easier?
   A. Caching of subtotal/total and reuse in invoices and reports
   B. Removing OrderLine
   C. Making price calculation public everywhere
   D. Avoiding any loops
   Answer: A. The subtotal can be cached and reused, and discount or tax changes are made in one place. (Key point: Other benefits)

## Related in Object Oriented Analysis and Design

- [Event management system summary and class diagram](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aoems-executive-summary-class-diagram) — Object Oriented Analysis and Design, chapter 2
- [Create classes from design class diagrams](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aclasses-from-design-class-diagram) — Object Oriented Analysis and Design, chapter 4, asked 2×
- [KUKL customer system design and code](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Akukl-use-case-class-diagram-code) — Object Oriented Analysis and Design, chapter 4
- [Constraint specifications in bank account model](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aconstraint-specification-bank-account-model) — Object Oriented Analysis and Design, chapter 2
- [XYZ Marina class diagram](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Amarina-class-diagram) — Object Oriented Analysis and Design, chapter 2
- [Four class relationships from figure](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aclass-relationships-from-figure) — Object Oriented Analysis and Design, chapter 2

## Related in other subjects

- [Canal outlet and module performance criteria](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Acanal-outlet-module-performance-criteria) — Irrigation and Drainage Engineering, chapter 7
- [Adjustable orifice semi-module design](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Aadjustable-orifice-semimodule-022) — Irrigation and Drainage Engineering, chapter 7
- [Second order model from step response (peak 1.25)](https://www.bctengineer.com/question.md?key=semester_3%2Fcontrol_systems%3Asecond-order-from-step-125) — Control Systems, chapter 3
- [Design goals and performance metrics](https://www.bctengineer.com/question.md?key=semester_5%2Fcomputer_organization_and_architecture%3Adesign-goals-metrics) — Computer Organization and Architecture, chapter 1