Implement the Observer Pattern for Event Notification

The Observer pattern is a fundamental behavioral design pattern that allows an object, known as the Subject, to notify a list of dependent objects, known as Observers, whenever its state changes. This is incredibly useful for decoupling components in an application, enabling them to communicate indirectly without direct knowledge of each other. Your task is to implement this pattern from scratch.

Problem Description

You need to create a flexible system for broadcasting events. This system will consist of two main components:

1. Subject (or Observable): An object that maintains a list of Observers and notifies them when its state changes.
2. Observer: An object that registers with a Subject and is notified by the Subject when a change occurs.

Key Requirements:

• The Subject must be able to have Observers added to and removed from its list.
• The Subject must provide a mechanism to trigger a notification to all its registered Observers.
• When a notification is triggered, each Observer's update mechanism should be called.
• The Observers should receive relevant data (the "state change") from the Subject when notified.

Expected Behavior:

When a Subject's state changes and it's told to notify, all currently attached Observers should receive this notification. An Observer should not be notified if it has been detached from the Subject.

Edge Cases:

• A Subject with no Observers attached should not throw an error when notified.
• An Observer should be able to be added multiple times, but only notified once per notification event (or be robust to duplicate registrations if desired, though a single notification is cleaner).
• An Observer that is removed should no longer receive notifications.

Examples

Example 1: Scenario: Simple data update notification

Subject: Creates a 'WeatherStation' subject.
Observer 1: Creates a 'CurrentConditionsDisplay' observer.
Observer 2: Creates a 'StatisticsDisplay' observer.

WeatherStation.attach(CurrentConditionsDisplay)
WeatherStation.attach(StatisticsDisplay)

WeatherStation.setState("30 degrees Celsius, sunny")
// This should trigger notifications to both observers.

CurrentConditionsDisplay.update("30 degrees Celsius, sunny")
StatisticsDisplay.update("30 degrees Celsius, sunny")

Example 2: Scenario: Detaching an observer and further updates

Subject: Creates a 'NewsPublisher' subject.
Observer A: Creates a 'SubscriberA' observer.
Observer B: Creates a 'SubscriberB' observer.

NewsPublisher.attach(SubscriberA)
NewsPublisher.attach(SubscriberB)

NewsPublisher.setState("Breaking News: New product launched!")
// SubscriberA.update("Breaking News: New product launched!")
// SubscriberB.update("Breaking News: New product launched!")

NewsPublisher.detach(SubscriberA)

NewsPublisher.setState("Important Announcement: Upcoming event details.")
// SubscriberB.update("Important Announcement: Upcoming event details.")
// SubscriberA should NOT be notified.

Constraints

• The implementation should be language-agnostic, using pseudocode.
• The Subject and Observer interfaces should be clearly defined.
• The data passed during notification can be a generic type or a simple string for demonstration.
• Assume the basic data structures (like lists or arrays) are available.

Notes

• Consider how you will manage the list of observers within the Subject.
• Think about the methods each Subject and Observer should expose.
• The core idea is broadcasting changes, so ensure your notification mechanism iterates through all attached Observers.
• You might consider different ways to pass the state change data to the Observers. For this challenge, passing the new state directly is sufficient.