Mixing
null object pattern unable to solve the problem of multiple return types
up vote
0
down vote
favorite
Sometimes users prefer not to disclose marital status, which is fine in my domain. So I have data where user is either married or not and I have data where I don't know the status. My goal is to make sure the function for marital status check as below returns only single type of data. Although I am using php but I am sure this applies to any language out there.
This is the interface
interface MaritalStatusInterface
{
public function status(): ?bool;
}
This means status can return true or false and in some cases null.
This was my implementation.
class MaritalStatus implements MaritalStatusInterface
{
const SINGLE = 0;
const MARRIED = 1;
private $status;
public function __construct(int $status)
{
if($status !== self::SINGLE && $status !== self::MARRIED)
{
throw new InvalidArgumentException("Given marital status '$status' is invalid. Marital status should be either single as " . self::SINGLE . " or married as " . self::MARRIED, 7263);
}
$this->status = $status;
}
public function status(): ?bool
{
return ($this->status)?true:false;
}
}
Now this is the null object when I am unable to get marital status data.
class NullMaritalStatus implements MaritalStatusInterface
{
private $status;
public function __construct()
{
$this->status = null;
}
public function status(): ?bool
{
return $this->status;
}
}
My question is I am unable to split the return type of Null object and real object status function. The primary benefit as per my understanding for using null object pattern is functions are more predictable as if it is bool return type then it will always return bool.
How can I refactor my code so that the function
public function status(): ?bool
can be written as
# for MaritalStatus class
public function status(): bool
and
# for NullMaritalStatus class
public function status(): null
Is it even possible? Surely that will not conform to MaritalStatusInterface. I am not sure if using multiple interfaces can solve it. Or am I looking it in a totally wrong manner and there is nothing wrong in having nullable return types?
php design-patterns null-object-pattern
asked 16 hours ago
Waku-2
187113
add a comment |
up vote
0
down vote
favorite
Sometimes users prefer not to disclose marital status, which is fine in my domain. So I have data where user is either married or not and I have data where I don't know the status. My goal is to make sure the function for marital status check as below returns only single type of data. Although I am using php but I am sure this applies to any language out there.
This is the interface
interface MaritalStatusInterface
{
public function status(): ?bool;
}
This means status can return true or false and in some cases null.
This was my implementation.
class MaritalStatus implements MaritalStatusInterface
{
const SINGLE = 0;
const MARRIED = 1;
private $status;
public function __construct(int $status)
{
if($status !== self::SINGLE && $status !== self::MARRIED)
{
throw new InvalidArgumentException("Given marital status '$status' is invalid. Marital status should be either single as " . self::SINGLE . " or married as " . self::MARRIED, 7263);
}
$this->status = $status;
}
public function status(): ?bool
{
return ($this->status)?true:false;
}
}
Now this is the null object when I am unable to get marital status data.
class NullMaritalStatus implements MaritalStatusInterface
{
private $status;
public function __construct()
{
$this->status = null;
}
public function status(): ?bool
{
return $this->status;
}
}
My question is I am unable to split the return type of Null object and real object status function. The primary benefit as per my understanding for using null object pattern is functions are more predictable as if it is bool return type then it will always return bool.
How can I refactor my code so that the function
public function status(): ?bool
can be written as
# for MaritalStatus class
public function status(): bool
and
# for NullMaritalStatus class
public function status(): null
Is it even possible? Surely that will not conform to MaritalStatusInterface. I am not sure if using multiple interfaces can solve it. Or am I looking it in a totally wrong manner and there is nothing wrong in having nullable return types?
php design-patterns null-object-pattern
asked 16 hours ago
Waku-2
187113
there is nothing wrong in having nullable return types?There is nothing wrong with that, if you are handlingnullproperly on the caller-side. For me the NullObject Pattern is an overengineering to solve problems that aren't really existing. In most the cases, the caller needs to deal with "null" values - so it doesn't matter, if you returnnullor aNullObject.
– dognose
16 hours ago
thanks for your insight, using NullObject seems overkill but it removes a lot of if statements in my current domain, so whether I like it or not but I need to get along with it unless I know something better which at the moment I don't. That's why I am asking
– Waku-2
16 hours ago
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Sometimes users prefer not to disclose marital status, which is fine in my domain. So I have data where user is either married or not and I have data where I don't know the status. My goal is to make sure the function for marital status check as below returns only single type of data. Although I am using php but I am sure this applies to any language out there.
This is the interface
interface MaritalStatusInterface
{
public function status(): ?bool;
}
This means status can return true or false and in some cases null.
This was my implementation.
class MaritalStatus implements MaritalStatusInterface
{
const SINGLE = 0;
const MARRIED = 1;
private $status;
public function __construct(int $status)
{
if($status !== self::SINGLE && $status !== self::MARRIED)
{
throw new InvalidArgumentException("Given marital status '$status' is invalid. Marital status should be either single as " . self::SINGLE . " or married as " . self::MARRIED, 7263);
}
$this->status = $status;
}
public function status(): ?bool
{
return ($this->status)?true:false;
}
}
Now this is the null object when I am unable to get marital status data.
class NullMaritalStatus implements MaritalStatusInterface
{
private $status;
public function __construct()
{
$this->status = null;
}
public function status(): ?bool
{
return $this->status;
}
}
My question is I am unable to split the return type of Null object and real object status function. The primary benefit as per my understanding for using null object pattern is functions are more predictable as if it is bool return type then it will always return bool.
How can I refactor my code so that the function
public function status(): ?bool
can be written as
# for MaritalStatus class
public function status(): bool
and
# for NullMaritalStatus class
public function status(): null
Is it even possible? Surely that will not conform to MaritalStatusInterface. I am not sure if using multiple interfaces can solve it. Or am I looking it in a totally wrong manner and there is nothing wrong in having nullable return types?
php design-patterns null-object-pattern
asked 16 hours ago
Waku-2
187113
Sometimes users prefer not to disclose marital status, which is fine in my domain. So I have data where user is either married or not and I have data where I don't know the status. My goal is to make sure the function for marital status check as below returns only single type of data. Although I am using php but I am sure this applies to any language out there.
This is the interface
interface MaritalStatusInterface
{
public function status(): ?bool;
}
This means status can return true or false and in some cases null.
This was my implementation.
class MaritalStatus implements MaritalStatusInterface
{
const SINGLE = 0;
const MARRIED = 1;
private $status;
public function __construct(int $status)
{
if($status !== self::SINGLE && $status !== self::MARRIED)
{
throw new InvalidArgumentException("Given marital status '$status' is invalid. Marital status should be either single as " . self::SINGLE . " or married as " . self::MARRIED, 7263);
}
$this->status = $status;
}
public function status(): ?bool
{
return ($this->status)?true:false;
}
}
Now this is the null object when I am unable to get marital status data.
class NullMaritalStatus implements MaritalStatusInterface
{
private $status;
public function __construct()
{
$this->status = null;
}
public function status(): ?bool
{
return $this->status;
}
}
My question is I am unable to split the return type of Null object and real object status function. The primary benefit as per my understanding for using null object pattern is functions are more predictable as if it is bool return type then it will always return bool.
How can I refactor my code so that the function
public function status(): ?bool
can be written as
# for MaritalStatus class
public function status(): bool
and
# for NullMaritalStatus class
public function status(): null
Is it even possible? Surely that will not conform to MaritalStatusInterface. I am not sure if using multiple interfaces can solve it. Or am I looking it in a totally wrong manner and there is nothing wrong in having nullable return types?
php design-patterns null-object-pattern
php design-patterns null-object-pattern
asked 16 hours ago
Waku-2
187113
asked 16 hours ago
Waku-2
187113
edited 16 hours ago
asked 16 hours ago
Waku-2
187113
asked 16 hours ago
Waku-2
187113
asked 16 hours ago
Waku-2
187113
187113
there is nothing wrong in having nullable return types?There is nothing wrong with that, if you are handlingnullproperly on the caller-side. For me the NullObject Pattern is an overengineering to solve problems that aren't really existing. In most the cases, the caller needs to deal with "null" values - so it doesn't matter, if you returnnullor aNullObject.
– dognose
16 hours ago
thanks for your insight, using NullObject seems overkill but it removes a lot of if statements in my current domain, so whether I like it or not but I need to get along with it unless I know something better which at the moment I don't. That's why I am asking
– Waku-2
16 hours ago
add a comment |
there is nothing wrong in having nullable return types?There is nothing wrong with that, if you are handlingnullproperly on the caller-side. For me the NullObject Pattern is an overengineering to solve problems that aren't really existing. In most the cases, the caller needs to deal with "null" values - so it doesn't matter, if you returnnullor aNullObject.
– dognose
16 hours ago
thanks for your insight, using NullObject seems overkill but it removes a lot of if statements in my current domain, so whether I like it or not but I need to get along with it unless I know something better which at the moment I don't. That's why I am asking
– Waku-2
16 hours ago
there is nothing wrong in having nullable return types? There is nothing wrong with that, if you are handling null properly on the caller-side. For me the NullObject Pattern is an overengineering to solve problems that aren't really existing. In most the cases, the caller needs to deal with "null" values - so it doesn't matter, if you return null or a NullObject.– dognose
16 hours ago
there is nothing wrong in having nullable return types? There is nothing wrong with that, if you are handling null properly on the caller-side. For me the NullObject Pattern is an overengineering to solve problems that aren't really existing. In most the cases, the caller needs to deal with "null" values - so it doesn't matter, if you return null or a NullObject.– dognose
16 hours ago
thanks for your insight, using NullObject seems overkill but it removes a lot of if statements in my current domain, so whether I like it or not but I need to get along with it unless I know something better which at the moment I don't. That's why I am asking
– Waku-2
16 hours ago
thanks for your insight, using NullObject seems overkill but it removes a lot of if statements in my current domain, so whether I like it or not but I need to get along with it unless I know something better which at the moment I don't. That's why I am asking
– Waku-2
16 hours ago
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53371633%2fnull-object-pattern-unable-to-solve-the-problem-of-multiple-return-types%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
there is nothing wrong in having nullable return types?There is nothing wrong with that, if you are handlingnullproperly on the caller-side. For me the NullObject Pattern is an overengineering to solve problems that aren't really existing. In most the cases, the caller needs to deal with "null" values - so it doesn't matter, if you returnnullor aNullObject.– dognose
16 hours ago
thanks for your insight, using NullObject seems overkill but it removes a lot of if statements in my current domain, so whether I like it or not but I need to get along with it unless I know something better which at the moment I don't. That's why I am asking
– Waku-2
16 hours ago