How can a ride-sharing app's ride-status notifications be an example of the Observer pattern even if the code has no class explicitly named Observer or Subject?

The Observer pattern's defining idea is that one object's state change automatically informs multiple dependent objects, without those dependents needing to poll for the change themselves. In a ride's status-update method, changing status and then calling notify on both the passenger and the driver through a shared inherited method matches that idea exactly -- one state change, several dependents informed automatically, in the same method call. A formal Observer interface with attach and detach methods for dynamically managing a list of subscribers is a common, more general implementation of that idea, but it is not required for the pattern to be genuinely present. What matters for recognizing the pattern is the underlying relationship between the subject and its dependents, not whether the class names or interface names match a textbook template.