Question about event driven design

[외계인 토리]

Hello. I am a student learning object-oriented development through OOSC and Touch of Class. I have been reading Touch of Class recently, and Chapter 18 made a strong impression on me and was of great help.

Event-driven architecture seems to fundamentally reshape the traditional client-supplier relationship. Originally, a class was a passive component that gathered related features and simply waited to be used. However, with the advent of event structures, a class gains some degree of choice over when its features are executed, by subscribing to particular event types. Additionally, instead of explicitly calling another object's features, it becomes possible to invoke them indirectly through event publication.

I have a few questions related to this. Would it be possible to get answers to the following here?

1. In this publish-subscribe relationship, how should one go about specifying and verifying the correctness of a class? That is, how does the publish-subscribe relationship affect design by contract? For a class that publishes events, is it mandatory to specify in a procedure's postcondition which events are published? For a class that subscribes to events, what should be specified and verified?
2. If this event publish-subscribe structure is used as the primary interface for inter-class interaction, what effect would it have on software quality? That is, all features of a class are declared as secret, and at creation time, those private features are registered with the appropriate event types. I often find myself writing such classes when doing web frontend development or game development with the game engine. My conjecture is that such classes lower coupling and therefore have good extensibility, but reusability would be poor. Could such a class sometimes be a good approach? And if so, could it be acceptable for such classes to constitute the majority of the codebase?