Какие кодировки или шаблоны проектирования можно использовать для обеспечения требуемой последовательности вызовов методов?

Question

я написал следующие строки кода:

$this->validate($group); 

$this->em->persist($group); 
$this->em->flush(); 

метод «проверки» будет сгенерировано исключение, если $ группа не является действительным. Проблема в том, что она кажется «хрупкой». Если другой разработчик изменил этот код, возможно, он случайно перенесет метод проверки, и диспетчер сущностей сохранит объект в базе данных без его проверки.

Считаете ли вы, что следующие строки кода лучше или я просто переусердствовал?

$validGroup = $this->validate($group); 

$this->em->persist($validGroup); 
$this->em->flush(); 

Есть ли какие-либо шаблоны для проверки?

Answer 1

Я бы подтвердил внутри persist, так что невозможно сохранить неутвержденный объект. Если em является сторонним кодом, и вы не хотите его изменять, оберните em в свой собственный объект, который проверяет перед записью в базу данных и использует ее всюду.

Есть несколько вариантов для проектирования em или вашей обертки, так что вам нужно только написать ее один раз и использовать один экземпляр в своей программе. Вы можете либо

• Дайте объекту нести ответственность за проверку себя, например. требуют, чтобы все устойчивые объекты имели метод is_valid. em или ваша обертка попросит объект проверить себя и выбросить исключение, если объект недействителен. Это, пожалуй, лучшее решение, если вы можете добавить поведение к стойким объектам, поскольку оно ставит идею достоверности в том же месте, что и данные.

• em или ваша обложка обнаруживает тип объекта, просматривает (в реестре или по именованию) объект проверки, который знает, как проверять объекты этого типа, попросите валидатор проверить проверяемый объект , и, опять же, введите исключение, если объект недействителен. Это сложнее, но может быть полезно, если проверка достаточно сложна, чтобы заслужить отдельный объект или необходимо, если вы не можете добавить поведение к устойчивым объектам.

Answer 2

Этот вопрос затрагивает очень важную и значительную проблему в дизайне интерфейса. Проблема заключается в «незадекларированном упорядочении», то есть порядок вызовов метода неявно и необъявлен. Это источник многих проблем и путаницы.

Существует два способа рефакторинга (по крайней мере). Оба уже представлены выше, я просто их обобщаю.

1. Используйте результат одного вызова метода как вход для другого вызова (как это уже делал OP). Это обеспечивает порядок. Он применим и полезен, когда результат первого вызова метода используется несколько раз.
2. Вызвать первый метод во втором методе (или наоборот). Это также решит проблему, так как пользователь интерфейса должен вызывать один метод.

Answer 3

Template Pattern подходит для этой проблемы.

В шаблоне шаблона абстрактный класс предоставляет определенные пути/шаблоны для выполнения своих методов. Его подклассы могут переопределять реализацию метода в соответствии с потребностью, но вызов должен быть таким же образом, как определено абстрактным классом. Эта модель относится к категории моделей поведения.

abstract class MyTemplate{ 
    void myPersist(){ 
     validate(); 
     persist(); 
     flush(); 
}