For your situation, it would probably be better to avoid modifying your Actor class hierarchy for this problem. Re-factoring your base Actor class to accommodate multiple textures will probably cause a ripple effect that will require you to re-code how your derived Actor classes use textures (which could be a hassle if you have a lot of derived Actor classes). On the other hand, creating a new kind of Actor class in your hierarchy just for multiple textures will make your code less flexible and more difficult to change if you later decide to change how your textures are used or displayed (eg. animation). It's better to use inheritance for "is-a" relationships rather than "has-a" relationships.
Therefore, I suggest you instead use a hierarchy for your textures. You could create a DualTexture class that inherits from your Texture class. Then, you could have this class contain two separate images. Any Actor that uses this kind of texture can modify the rotation of one or both of the images through the public methods of DualTexture. Thus, your NPCs could use this kind of texture and handle the game logic to rotate the "cannon" part of the texture without modifying the "base" part of the texture.
Alternatively, if you might be later adding actors made up of more than 2 textures, you can instead make a MultiTexture class for your texture hierarchy. This texture class could contain N images in a list. As a result, any actor using this texture class would be able to have as many textures as it needs.