###Background

Inheritance is a powerful tool that serves a purpose in object-oriented programming. However, it does not solve every problem elegantly: sometimes, other solutions are better.

If you think back to your early computer science classes (assuming you have a CS degree) you may remember a professor giving you a paragraph that states what the customer wants the software to do. Your job is to read the paragraph, identify the actors and actions, and come away with a rough outline of what the classes and methods are. There will be some bum leads in there that look like they are important, but are not. There is a very real possibility of misinterpreting requirements as well.

This is an important skill that even the most experienced of us get wrong: properly identifying requirements and translating them into machine languages.

###Your Question

Based on what you have written, I think you may be misunderstanding the general case of optional actions that classes can perform. Yes, I know your code is just an example and you are interested in the general case. However, it sounds like you want to know how to handle the situation where certain subtypes of an object can perform an action, but other subtypes cannot.

Just because an object such as an account has an account type does not mean that translates into a type in an OO language. "Type" in a human language does not always mean "class." In the context of an account, "type" may more closely correlate with "permission set." You want to use a user account to perform an action, but that action may or may not be able to be performed by that account. Rather than using inheritance, I would use a delegate or security token.

###My Solution

Consider an account class that has several optional actions it can perform. Instead of defining "can perform action X" via inheritance, why not have the account return a delegate object (password resetter, form submitter, etc) or an access token?

account.getPasswordResetter().doAction();
account.getFormSubmitter().doAction(view.getContents());

AccountManager.resetPassword(account, account.getAccessToken());

The benefit to the last option there is what if I want to use my account credentials to reset someone else's password?

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

Not only is the system more flexible, not only have I removed type casts, but the design is more expressive. I can read this and easily understand what it is doing and how it can be used.

TL;DR: this reads like an XY problem. Generally when faced with two options that are suboptimal, it is worth taking a step back and thinking "what am I really trying to accomplish here? Should I really be thinking about how to make the typecasting less ugly, or should I look for ways to remove the typecast entirely?"

Background

Inheritance is a powerful tool that serves a purpose in object-oriented programming. However, it does not solve every problem elegantly: sometimes, other solutions are better.

If you think back to your early computer science classes (assuming you have a CS degree) you may remember a professor giving you a paragraph that states what the customer wants the software to do. Your job is to read the paragraph, identify the actors and actions, and come away with a rough outline of what the classes and methods are. There will be some bum leads in there that look like they are important, but are not. There is a very real possibility of misinterpreting requirements as well.

This is an important skill that even the most experienced of us get wrong: properly identifying requirements and translating them into machine languages.

Your Question

Based on what you have written, I think you may be misunderstanding the general case of optional actions that classes can perform. Yes, I know your code is just an example and you are interested in the general case. However, it sounds like you want to know how to handle the situation where certain subtypes of an object can perform an action, but other subtypes cannot.

Just because an object such as an account has an account type does not mean that translates into a type in an OO language. "Type" in a human language does not always mean "class." In the context of an account, "type" may more closely correlate with "permission set." You want to use a user account to perform an action, but that action may or may not be able to be performed by that account. Rather than using inheritance, I would use a delegate or security token.

My Solution

Consider an account class that has several optional actions it can perform. Instead of defining "can perform action X" via inheritance, why not have the account return a delegate object (password resetter, form submitter, etc) or an access token?

account.getPasswordResetter().doAction();
account.getFormSubmitter().doAction(view.getContents());

AccountManager.resetPassword(account, account.getAccessToken());

The benefit to the last option there is what if I want to use my account credentials to reset someone else's password?

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

Not only is the system more flexible, not only have I removed type casts, but the design is more expressive. I can read this and easily understand what it is doing and how it can be used.

TL;DR: this reads like an XY problem. Generally when faced with two options that are suboptimal, it is worth taking a step back and thinking "what am I really trying to accomplish here? Should I really be thinking about how to make the typecasting less ugly, or should I look for ways to remove the typecast entirely?"