incapsulation and non exposing internals vs SRP - php

Question

Is code like this is a bad? :
public class TierType
{
private const TYPE_HARD = 'hard';
private const TYPE_MEDIUM = 'medium';
private const TYPE_SOFT = 'soft';
private const SUPPORTED_TYPES = [
self::TYPE_HARD,
self::TYPE_MEDIUM,
self::TYPE_SOFT
];
private function _construct(private string $type) {
}
public static function fromString(string $tierType): self
{
return match ($tierType) {
self::TYPE_HARD => new self(self::TYPE_HARD),
self::TYPE_MEDIUM => new self(self::TYPE_MEDIUM),
self::TYPE_SOFT => new self(self::TYPE_SOFT),
default => throw new Exception('Unsupported tier type provided'),
};
}
public static function createHard(): self
{
return new self(self::self::TYPE_HARD)
}
public static function createMedium(): self
{
return new self(self::self::TYPE_MEDIUM)
}
public static function createSoft(): self
{
return new self(self::self::TYPE_SOFT)
}
}
In this example we not exposing internals of the object, and not delegating creation of the object to outer world, and it's a way I like to do it, and doing for a while already. But recently I heard that is' wrong and it's breaking a SRP as it's not responsibility of object to create it self, and you need to have a public constructor and initiate object from factory. Like this:
public class TierType
{
public const TYPE_HARD = 'hard';
public const TYPE_MEDIUM = 'medium';
public const TYPE_SOFT = 'soft';
public const TYPE_EXTRA_SOFT = 'extra_soft';
private const SUPPORTED_TYPES = [
self::TYPE_HARD,
self::TYPE_MEDIUM,
self::TYPE_SOFT
];
public function _construct(private string $type) {
if (!in_array($this->type, self:::SUPPORTED_TYPES) {
throw new Exception('Unsupported tier type provided')
}
}
}
public class TierFactory {
public function create(string $type): TierType
{
return match ($type) {
self::TYPE_HARD => new TierType(TierType::TYPE_HARD),
self::TYPE_MEDIUM => new TierType(TierType::TYPE_MEDIUM),
self::TYPE_SOFT => new TierType(TierType::TYPE_SOFT),
default => throw new Exception('Unsupported tier type provided'),
};
}
public static function createHard(): TierType
{
return new TierType(TierType::TYPE_HARD)
}
public static function createMedium(): TierType
{
return new TierType(TierType::TYPE_MEDIUM)
}
public static function createSoft(): TierType
{
return new TierType(TierType::TYPE_SOFT)
}
}
I think it also okay, but in this case it's probably unnecessary to create factory as logic is simple, and we allowing other devs to omit that factory and directly call TierType constuctor or create other types of factories. Hopefully we have a validation in the constructor but what if not?? it's harder to thing about object state and add all validation when you delegating it to many classes. From other hadn I think class should tell it's self how to create it, and provide interface of creation. I agree that factory make sense if logic of creation is complicated and some part of it it's not related to object, for example we need to take data from different sources, combine it somehow and after that pass to the object, in that case it's not object responsibility.
Am I thinking correctly??? Or it's really breaking SRP and it's okay to delegate it to factory???

Answer 1

Single Responsibility should be understood as an abstraction of logical tasks in your system. A class should have the single responsibility to perform one single, specific task. A class that manages its own creation doesn't necessarily violates SRP.
That being said, there is a third option to do this that seems more elegant for your specific example. Create separate classes for each different types, each class extending from a common class:
public class TypeHard extends TierType implements TierTypeInterface {
public function __construct()
{
parent::__construct(parent::TYPE_HARD);
}
}
This way is also easier to use with autowired DI containers.