Scribd
Upload
83 views3 pages

CS 2401 DP Unit 7

The document outlines the implementation of the Publish-Subscribe design pattern for an online auction site, identifying classes that will act as publishers (ItemInfo, BidsList, AuctionController) and subscribers (BuyerInfo, SellerInfo, NotificationService). Publishers notify subscribers about relevant events, allowing for a decoupled architecture that enhances system flexibility and responsiveness. The document also provides example interfaces for publishers and subscribers and discusses their responsibilities.

Uploaded by

Proff Hado Moonga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
83 views3 pages

CS 2401 DP Unit 7

The document outlines the implementation of the Publish-Subscribe design pattern for an online auction site, identifying classes that will act as publishers (ItemInfo, BidsList, AuctionController) and subscribers (BuyerInfo, SellerInfo, NotificationService). Publishers notify subscribers about relevant events, allowing for a decoupled architecture that enhances system flexibility and responsiveness. The document also provides example interfaces for publishers and subscribers and discusses their responsibilities.

Uploaded by

Proff Hado Moonga
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Hi friends,

To implement the Publish-Subscribe (Observer) design pattern in the online auction site
described in Problem 2.31, we need to identify which classes will act as publishers and which
will act as subscribers. The goal of this pattern is to allow certain classes (publishers) to
notify other classes (subscribers) about changes or events without the subscribers needing to
be tightly coupled to the publishers.

Classes to Implement the Publisher Interface

1. ItemInfo: This class represents an individual auction item. It should implement the
Publisher interface because when the status of an item changes—such as when it is reserved,
when new bids are placed, or when the auction is closed—it should notify interested parties
(subscribers) about these changes.

2. BidsList: This class manages the collection of bids for an item. It should also implement
the Publisher interface because whenever a new bid is added or an existing bid is removed, it
should notify subscribers about the updated list of bids.

3. AuctionController (a new class): This class could serve as the central controller for
auction activities. It can publish events related to auction status, such as starting or closing an
auction, which may be of interest to subscribers like buyers and sellers.

Classes to Implement the Subscriber Interface

1. BuyerInfo: This class represents a buyer in the auction. Buyers should subscribe to
notifications from the ItemInfo and BidsList classes so they can receive updates when new
bids are placed on items they are interested in or when an auction they are watching is closed.

2. SellerInfo: This class represents a seller in the auction. Sellers should also subscribe to
notifications from ItemInfo and BidsList to be informed about bid updates and auction
statuses for their listed items.

3. NotificationService (a new class): This class could act as a mediator for notifications. It
can receive updates from publishers and manage the delivery of these notifications to all
relevant subscribers (buyers and sellers).

Explanation
- Publisher Responsibilities: The publisher classes (ItemInfo, BidsList, and
AuctionController) will maintain a list of subscribers (buyers and sellers) that have expressed
interest in receiving updates. They will notify these subscribers whenever a relevant event
occurs, such as a new bid being placed or an auction closing.

- Subscriber Responsibilities: The subscriber classes (BuyerInfo and SellerInfo) will


implement methods to handle notifications. For example, when a new bid is placed, a buyer
might want to be notified so they can decide whether to place a higher bid. Similarly, sellers
need to be informed when their items receive bids or when the auction closes, allowing them
to take appropriate actions.

- Decoupling: This design pattern allows for a decoupled architecture where publishers do
not need to know about the details of their subscribers. This makes the system more flexible
and easier to maintain, as changes in one part of the system (e.g., adding new types of
subscribers) do not require changes in the publisher classes.

Example Class Interfaces

Here’s a rough outline of what the Publisher and Subscriber interfaces might look like:

```java

// Publisher Interface

public interface Publisher {

void registerSubscriber(Subscriber subscriber);

void unregisterSubscriber(Subscriber subscriber);

void notifySubscribers(String message);

// Subscriber Interface

public interface Subscriber {

void update(String message);


}

```

Implementation

- In ItemInfo:

- When an item is reserved or when bids are updated, the `notifySubscribers` method
would be called to inform all registered buyers and sellers.

- In BidsList:

- When a new bid is added, it would notify subscribers about the new bid, allowing buyers
to react accordingly.

- In AuctionController:

- It could notify all interested parties when an auction starts or closes.

In conclusion, implementing the Publish-Subscribe pattern in the online auction site enhances
the system's responsiveness and flexibility, allowing users to stay informed about relevant
events without creating tight coupling between the different components of the system
(Gamma et al., 1994).

References

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley.

You might also like