Да, есть эмпирические правила. Инструменты анализа кода - хорошее начало для этого.
Некоторые правила о вашем коде:
Плохая практика разрешать сеттеры для свойств коллекции. Это связано с тем, что обращаться с пустыми коллекциями просто, как с полными в коде. Заставляя людей делать нулевые проверки коллекций, вы будете побеждены. Рассмотрим следующий фрагмент кода:
public bool IsValid(object input){
foreach(var validator in this.Validators)
if(!validator.IsValid(input)
return false;
return true;
}
Этот код работает независимо от того, является ли коллекция валидаторов пустой или нет. Если вы хотите проверки, добавьте валидаторы в коллекцию. Если нет, оставьте коллекцию пустой. Просто. Если для свойства collection задано значение NULL, эта вонючая версия кода приведена выше:
public bool IsValid(object input){
if(this.Validators == null)
return false;
foreach(var validator in this.Validators)
if(!validator.IsValid(input)
return false;
return true;
}
Больше строк кода, менее элегантно.
Во-вторых, для ссылочных типов ДРУГИЕ, чем коллекции, вы должны учитывать поведение объекта при определении, хотите ли вы установить значения свойств. Существует ли единственное очевидное значение по умолчанию для свойства? Или нулевое значение для свойства имеет допустимое значение?
В вашем примере вы можете всегда проверять в установщике значение Name и устанавливать его по умолчанию "(имя не указано)", когда ему присваивается значение NULL. Это может облегчить привязку этого объекта к пользовательскому интерфейсу. Или имя может быть нулевым, поскольку вы ТРЕБУЕТЕ правильное имя, и вы будете проверять его и генерировать исключение InvalidOperationException, когда вызывающая сторона пытается выполнить действие над объектом без предварительной установки имени.
Как и большинство вещей в программировании, есть куча разных способов сделать что-то, половина из которых плохая, и каждый способ в другой половине хорош только при определенных обстоятельствах.