Цитата:
Сообщение от
Raven Melancholic
Ну а для случаев, когда не нужны сообщения, предпочитаем называть методы не check*, а как-то по другому - is*, has* и т. п.
Я бы еще дополнительно классифицировал проверки на пользовательские (т.е. те, которые понятны пользователю и сообщение о проверке необходимо пользователю для дальнейших его действий) и все остальные.
Отсюда вывод, что в методах check* всегда должно быть какое-то осмысленное для пользователя сообщение об ошибке.
Например, проверка на закрытость периода, наличие товара / бюджета - пользовательские. А проверка на наличие записи в таблице - не пользовательская.
Соответственно, в методы check* я бы убрал пользовательские проверки, а в методы is*, has* - непользовательские.
При этом надо понимать, что одна и та же проверка может быть одновременно пользовательской и не пользовательской в зависимости от задачи.
Например, я хочу сделать недоступным поле "Группа номенклатурных моделей", если есть проводки по номенклатуре. В этом случае проверка на наличие проводок будет непользовательской (метод hasInventTrans)
Но я могу захотеть не делать недоступным поле, а выдать ошибку при попытке его изменения, если уже есть проводки. В этом случае проверка будет пользовательской (метод checkExistsInventTrans) с осмысленной ошибкой "По данной номенклатуре уже есть движения".
При этом мне никто не запрещает метод checkExistsInventTrans сделать просто оберткой метода hasInventTrans, но с дополнительным выводом сообщения.
Опять-таки - это все красиво и замечательно, пока есть время и возможность "сделать по феншую". Когда сроки уже начинают поджимать или закрываешь какую-то горящую проблему "по-быстрому" то "феншуй" нередко откладывается в сторону, особенно, если его детали приходится вспоминать.