a menos que numero sea static no podras que el objeto B a su vez tenga un objeto A seria ilogico xD

Respuesta corta
- lo más probable es que estés confundido y que estés volteando las relaciones es decir que b contenga a y no al revés pero es difícil saber si eso es correcto si no pones el ejemplo concreto que estas usando
-si realmente se debes ejecutar código después de otra cosa eso lo puedes a mano (muy poco recomendado) o usando el patrón observador

Para el flame
-siempre me confundo cuando hablan de un a que dentro de una b que llama a un no sé que habla en cosas concretas con código (clase carro factura persona empleado servicio de impresion etc)


cuando eso pasa lo más probable es que hay un mal diseño(no siempre a veces no tiene opción) y la sospecha es que a y b deban heredar de una clase abstracta(no entiendo porque nunca la usan si les han enseñado como se hace) esa clase abstracta tiene que tener el código común que deben tener todos sus hijos es recomendable que una clase abstracta implemente una interface(para definir un contrato y reducir al máximo el acoplamiento) y que la clase abstracta implemente esa interface y que escriba la implementación por defecto(para que los hijos no tengan código repetido) de la mayoría de los métodos de la interface ejemplo tablemodel abstracttablemodel y defaultablemodel

Ejemplo de la pesadilla del mal uso de herencia son las versiones antiguas de ejb(eso fue un fiasco y existimos muchos haters de ejb) cada objeto de negocio(casi nunca son pocas) tenían que heredar de abstractnisiquieralopuedopronunciarlo y luego implementar sus todos sus métodos creo que son 4 es decir que si tienes 25 objetos de negocio(facutra carro persona,etc) tenias que implementar 100 métodos al estilo copy paste
existen librerías que las denomina poco intrusivas (sin comillas) jpa jdo hibernate ultima versión de ejb que usan muy pocas clases y herencia (me gustan mucho) por la misma razón que sitas "para evitar la necesidad de atorarse con herencia múltiple" ellas usan principalmente anotaciones y programación orientada a aspectos(sin que el programador lo sepa)

-eso de que java no tiene herencia múltiple si friega y muy raras veces te encuentras con ese tipo de problemas y después de mucho pensarlo la solución es simple no uses herencia a menos que tengas una buena razón para hacer es recomendable usar herencia cuando es tu propio código y puedas cambiarlo como se te da la gana
Solo usa herencia cuando algo tenga relación de "es un" (un perro es un mamífero) además si es posible que la relación entre clases sea "tiene un" (una persona tiene una cabeza) es mejor no usar herencia no usar herencia solo por el pretexto "es que se parecen mucho y quiero ahorrar código"

-en caso de que la fregaste usaste herencia o la usaste mal(le malograste el diseño a los futuros programadores) te queda pocas opciones usar aspectos(forzando "herencia múltiple" a la mala) o hacer que los clientes tengan que implementar una interface(generalmente la solución es miserable teniendo 100 de clases con implementación repetitiva y que se tiene que mantener) otra opción la mejor pero de lejos la más compleja es que otra clase cree un objeto te implemente una interface ejemplo tu le pasas una factura y te crea un objeto de tipo observable

Observable facutraObserVable = new CreadorObservable(new Factura()).obtener();
Persistible productoPerisitible = new CreadorPersistible(new Producto()).obtener();
Disculpa que escriba mucho pero es que tengo demonios que exorcizar  y es mejor escribir que andar golpeando a todos los programadores con los que no comparto mis puntos de vista