There are similar things going on in my app. For example, a user could click a "close" icon on one component, which causes it to destroy itself, and also causes another component to move a toggle switch to an off position.
I elected to use events to handle these. I considered using bound attributes or methods, but decided to try and make the components more standalone and not need a bunch of variable bindings or method calls. The event mechanism allows me to send an event when a component does something (such as "I'm being closed") and have other components listen for that and take action. That way, the component that initiates the event doesn't have to worry about communication channels with recipients (such as attributes or method calls), it just fires an event, and it's up to other components to listen for those if they're interested. I happen to use application events instead of component events, only because I didn't want to concern myself with bubbling order. To me, application events were easier to work with, so that's what I stuck with.
If you wanted to go with an event approach, your Component 2 could fire some kind of "Validation complete" event at the end of the validation logic. The event could also contain attribute values, if those are needed for recipients to do their processing. Component 1 could listen for those events and based on the event, attributes, and/or target, take appropriate action, such as refreshing itself.
Hope this info helps!