Return to Answer

Should an object's capabilities be identified exclusively by the interfaces it implements?

An objects capabilities should not be identified at all.

The client using an object shouldn't be required to know anything about how it works. The client should only know things it can tell the object to do. What the object does, once it's been told, is not the clients problem.

So rather than

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

or

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

consider

account.ResetPassword();

or

account.ResetPassword(authority);

Because account already knows if this will work. Why ask it? Just tell it what you want and let it do whatever it's going to do.

Imagine this done in such a way that the client doesn't care if it worked or not because that's something elses problem. The clients job was only to make the attempt. It's done that now and it's got other things to deal with. This style has many names but the name I like the most is tell, don't ask.

It's very tempting when writing the client to think you have to keep track of everything and so pull towards you everything you think you need to know. When you do that you turn objects inside out. Value your ignorance. Push the details away and let the objects deal with them. The less you know the better.

Should an object's capabilities be identified exclusively by the interfaces it implements?

An objects capabilities should not be identified at all.

The client using an object shouldn't be required to know anything about how it works. The client should only know things it can tell the object to do. What the object does, once it's been told, is not the clients problem.

So rather than

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

or

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

consider

account.ResetPassword();

or

account.ResetPassword(authority);

because account already knows if this will work. Why ask it? Just tell it what you want and let it do whatever it's going to do.

Imagine this done in such a way that the client doesn't care if it worked or not because that's something elses problem. The clients job was only to make the attempt. It's done that now and it's got other things to deal with. This style has many names but the name I like the most is tell, don't ask.

It's very tempting when writing the client to think you have to keep track of everything and so pull towards you everything you think you need to know. When you do that you turn objects inside out. Value your ignorance. Push the details away and let the objects deal with them. The less you know the better.

Should an object's capabilities be identified exclusively by the interfaces it implements?

An objects capabilities should not be identified at all.

The client using an object shouldn't be required to know anything about how it works. The client should only know things it can tell the object to do. What the object does once it's told to do things is not the clients problem.

So rather than

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

or

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

consider

account.ResetPassword();

or

account.ResetPassword(authority);

Because account already knows if this will work. Why ask it? Just tell it what you want and let it do whatever it's going to do.

Imagine this done in such a way that the client doesn't care if it worked or not because that's something elses problem. The clients job was only to make the attempt. It's done that now and it's got other things to deal with. This style has many names but the name I like the most is tell, don't ask.

It's very tempting when writing the client to think you have to keep track of everything and so pull towards you everything you think you need to know. When you do that you turn objects inside out. Value your ignorance. Push the details away and let the objects deal with them. The less you know the better.

Should an object's capabilities be identified exclusively by the interfaces it implements?

An objects capabilities should not be identified at all.

The client using an object shouldn't be required to know anything about how it works. The client should only know things it can tell the object to do. What the object does, once it's been told, is not the clients problem.

So rather than

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

or

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

consider

account.ResetPassword();

or

account.ResetPassword(authority);

Because account already knows if this will work. Why ask it? Just tell it what you want and let it do whatever it's going to do.

Imagine this done in such a way that the client doesn't care if it worked or not because that's something elses problem. The clients job was only to make the attempt. It's done that now and it's got other things to deal with. This style has many names but the name I like the most is tell, don't ask.

It's very tempting when writing the client to think you have to keep track of everything and so pull towards you everything you think you need to know. When you do that you turn objects inside out. Value your ignorance. Push the details away and let the objects deal with them. The less you know the better.

Should an object's capabilities be identified exclusively by the interfaces it implements?

An objects capabilities should not be identified at all.

The client using an object shouldn't be required to know anything about how it works. The client should only know things it can tell the object to do. What the object does once it's told to do things is not the clients problem.

So rather than

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

or

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

consider

account.ResetPassword();

or

account.ResetPassword(authority);

Because account already knows if this will work. Why ask it? Just tell it what you want and let it do whatever it's going to do.

Imagine this done in such a way that the client doesn't care if it worked or not because that's something elses problem. The clients job was only to make the attempt. It's done that now and it's got other things to deal with. This style has many names but the name I like the most is tell, don't ask.

It's very tempting when writing the client to think you have to keep track of everything and so pull towards you everything you think you need to know. When you do that you turn objects inside out. Value your ignorance. Push the details away and let the objects deal with them. The less you know the better.

Should an object's capabilities be identified exclusively by the interfaces it implements?

An objects capabilities should not be identified at all.

The client using an object shouldn't be required to know anything about how it works. The client should only know things it can tell the object to do. What the object does once it's told to do things is not the clients problem.

So rather than

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

or

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

consider

account.ResetPassword();

or

account.ResetPassword(authority);

Because account already knows if this will work. Why ask it? Just tell it what you want and let it do whatever it's going to do.

Imagine this done in such a way that the client doesn't care if it worked or not because that's something elses problem. The clients job was only to make the attempt. It's done that now and it's got other things to deal with. This style has many names but the name I like the most is tell, don't ask.

It's very tempting when writing the client to think you have to keep track of everything and so pull towards you everything you think you need to know. When you do that you turn objects inside out. Value your ignorance. Push the details away and let the objects deal with them. The less you know the better.