Should my class subscribe to its own public events?

Question

I am using C# 3.0. Following the standard event pattern I have:

    public event EventHandler<EventArgs> SomeEventHappens;

    protected virtual void OnSomeEventHappens(EventArgs e)
    {
        if (SomeEventHappens != null)
        {
            SomeEventHappens(this, e);
        }
    }

    private object _someProperty;

    public object SomeProperty
    {
        get
        {
            return _someProperty;
        }
        private set
        {
            if (_someProperty == value)
            {
                return;
            }
            OnSomeEventHappens(EventArgs.Empty);
            _someProperty = value;
        }
    }

Within my same class I would like to take some actions when SomeProperty changes. The way I see it I have 3 alternatives:

1) Do stuff within my SomeProperty setter. Something rubs me the wrong way about doing this since I try to subscribe to the philosophy of everything should do one thing and do it well. Cramming stuff into a setter seems to go against that, or at least has the propensity to.

2) Do stuff in OnSomeEventHappens. Again, seems to go a little against keeping this in simple pieces. Also, if this method gets overridden, could potentially lose functionality if the implementer does not call the base method.

3) Have the class subscribe to SomeEventHappens. To me this seems to be the proper choice as far as encapsulation is concerned, and seems pretty clean. Again, possible repercussions if OnSomeEventHappens is overridden.

Maybe there is something more elegant? I cannot decide between option 2 and 3, and I am curious as to what the Best Practice is. Maybe the safest place is in the property setter after all.

Thoughts?

Update: Thanks for the great comments and answers below. I have learned that it is "OK" to have a class subscribe to its own events, although in my case I am leaning to not do due to overhead. I have put thought into the behavior of potential overriders of my virtual methods and what exactly I want to happen.

In my real-world case, I do not really want the events to be raised without the property being set. As the answers below have guided my thought process, I think I may go with option 1, due to the lower overhead, the reduced risk of improper behavior from inheritors, and it just generally makes better sense to me. Thanks again!

Answer 1

If you call SomeEventHappens and OnSomeEventHappens from some common location (the property procedure or another function), then you don't have to worry about overriders neglecting to raise the event. I would prefer to override a function rather than handle events because there's less overhead.

Answer 2

In object frameworks outside of .NET, an object that subscribes to its own events is frowned upon primarily because such things lead to circular references that could keep the object alive indefinitely. This is not an issue in .NET, but it still seems "strange" to me for a object to grope itself this way.

If a class always needs to be aware of when changes happen to the property, your best bet IMO is to make the OnSomeEventHappens method virtual and override it in descendant classes that need the additional info. It's ok to put code in the event firing method. The event firing method is there precisely so that everyone who wants to fire that event has a uniform way to do it.

If you only occasionally need to be informed of when the property changes, then I suppose subscribing and unsubscribing to the event would be appropriate.