It's a tough shift in thinking going from procedural to OO, for sure.
It's a fun journey though!

That is what's known as composition. Sometimes it certainly is a better
fit than inheritance, but in the case of your SignaledVector class you
are making a more specialized version of Vector. Your coworker is wrong
to chastise you for your design choice here, IMHO.

If the intention of SignaledVector is to be a special type of Vector,
which performs all the normal collection related functions of a Vector,
with some extra behavior tacked on (which is how it looks to me), then
you are on the right track!

I agree, it would be very silly to use a has-as relationship and duplicate
the entire vector contract.  If you want it to act like a vector, you did
the right thing.

However, I'm not sure if you decision to create an object which acts like a
vector is the right choice.  You would have to tell us more about your
application and what you were putting in that vector to allow us to suggest
a different way to fracture your code to solve the problem.

Extending classes you don't have control over can be a risky business.
What happens if the Java guys decide to add a "SignalAll" to the Vector
class? (highly  unlikely, but this is just an example).  If they not only
added that method in some future release but the Vector would call it's own
signalAll method at times, your version of the method could end up breaking
their code if it didn't happen to do just the right thing.

Using has-a relationships instead of is-a relationships in general is far
safer.

You could have for example made a simple object which held the Vector and
implemented the signal and signalAll methods on the vector as you did, as
well as a getter to get the vector.  To use the Vector methods, you just
get the vector from the object and use the Vector methods on the vector
instead of trying to make your object be a vector.

Though in OO terms, you did the right thing based on your description, as a
practical mater of code maintenance, it might have been better to approach
it differently.

On a larger scale, surely there is more you have to do with the objects in
the vector than send these signals to them right?  What puts the objects in
the Vector and what takes them out? What type of objects are in the Vector?
In general, when I find I need to do something to a Vector (like perform a
method on every object in the Vector) it would be highly unlikely that I
would end up approaching it like you did and extend the Vector class.

I'm sitting at my car dealer writing this message so let me make up an
example based on that.  Lets say I needed to represent the inventory of the
dealer as a collection of cars.  And one of the functions I needed to
perform on the collection was to add up the wholesale price of all the
calls to get a total value of the inventory.  I could do this like you did
by extending Vector to create a CarVector class and include in that class a
totalWholesaleCost method which would call the wholeSaleCost method of each
car in the Vector and return the sum.  But I would not tend to do that.

Instead, I would create a CarDealer Object which had an inventory variable
which was a Vector<Car>.  And I would but the totalWholesaleCost method in
the CarDealer object.  It's likely the CarDealer object would have other
instance variables as well such as the name of the dealer.  There would be
no need to create a special CarVector class to make any of this work just
because there were things I needed to do to the objects in the Vector.  So
this is an example of the CarDealer class using the has-a relationship with
the Vector instead of using the is-a relationship.

It's hard to tell whether the has-a relationship might work for you without
understanding more about your application.