Revisions to What is a good design for a method that can return several logically different results?

deleted 56 characters in body

edited Jul 21, 2014 at 17:09

603
5
7

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { public bool Result { get; private set; } public string NewPassword { get; private set; } public DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { public bool Result { get; private set; } public string NewPassword { get; private set; } public DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { public bool Result { get; private set; } public DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

added 21 characters in body

Source Link

edited Jul 21, 2014 at 4:10

Despertar

603
5
7

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { public bool Result { get; private set; }   public string NewPassword { get; private set; }   public DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { bool Result { get; private set; } string NewPassword { get; private set; } DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { public bool Result { get; private set; }   public string NewPassword { get; private set; }   public DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

added 307 characters in body

Source Link

edited Jul 20, 2014 at 23:16

Despertar

603
5
7

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { bool Result { get; private set; } string NewPassword { get; private set; } DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { bool Result { get; private set; } string NewPassword { get; private set; } DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

I think this approach is over-using inheritance which adds additional (unnecessary) complexity. Favor composition over inheritance when possible. Especially if it's a Success/Non-Success thing that is easily represented with a boolean it doesn't warrant the need for sub-classing.

You could include everything you need to into a single class, and based on the result you can use the properties accordingly. The class still has a single purpose, to return information about the password change. The fact that there are several different outcomes is an essential complexity of the task.

class ChangePasswordResult { bool Result { get; private set; } string NewPassword { get; private set; } DateTime ExpirationDate { get; private set; } public bool WasPasswordLongEnough { get; private set; } public bool DoesPasswordHaveToContainNumbers { get; private set; } }

Edit:

jhewlett Brings up a very good point too about serialization. With a single result structure being returned you have a more stable interface clients can interact with. When you document your interface you can say "this endpoint returns X" as opposed to "this endpoint returns X OR Y depending on..."