Я читал, что шаблон нулевого объекта поможет вам избежать исключений null и исключений нулевого указателя, что сделает ваш код более понятным.Является ли шаблон Null Object занимают память
Я никогда не использовал его, и мне это интересно. «null» не будет занимать память, но если я начну заменять свои нулевые проверки созданием объектов «по умолчанию», будет ли эта процедура негативно влиять на память в долгосрочной перспективе?
например:
Нуль шаблона объекта
public void DoSomething()
{
User user = this.GetUser(id);
string strDisplayName = user.DisplayName;
}
public User GetUser(int id)
{
User user = this.LoadUserFromDB(id);
if(user == null)
return User.CreateNull();
return user;
}
Таким образом, как только выходить из сферы методы, объект будет собран GC позже. Но что, если я пройду через цикл, прежде чем выйти из сферы действия.
public void DoSomething()
{
users = this.GetAllUsers();
foreach(User user in users)
{
string strAddress = user.Address.StreetName;
//continue tasks
}
}
Между тем в другом классе
public Class User
{
public Address Address
{
get
{
if(this.Address == null)
this.Address = Address.CreateNull();
return this.Address;
}
}
}
public class Address
{
private string streetName;
public virtual string StreetName
{
get { return this.streetName; }
set { this.streetName = value; }
}
public static CreateNull()
{
return new NullAddress();
}
}
public class NullAddress : Address
{
public override string StreetName
{
get { retun String.Empty; }
}
}
Null проверки
User user = this.GetUser(id);
string strDisplayName = String.Empty;
if(user != null)
{
strDisplayName = user.DisplayName;
}
Просто проверить, если пользователь не является нулевым, поэтому присвоить значение свойства. Я не буду создавать объект «нулевой»
Заранее благодарен.
Возможно, просто предпочтение, но в случае сущностей базы данных я бы подумал об использовании 'Optional' вместо «поддельных» пользователей, потому что 'Optional' сохраняет значение« no user found ». Реальные нулевые объекты работают только хорошо в тех случаях, когда это не приводит к путанице между надлежащими объектами и нулевой заменой (см. [Принцип подстановки Лискова] (https://en.wikipedia.org/wiki/Liskov_substitution_principle)). Как пустой 'List' вместо' null'. Или реализации, которые просто потребляют входные данные, такие как регистратор. –
zapl
Вне проблемы с памятью, где Джон говорит, что объекты должны быть разделены, я не уверен, что код для восходящего кода, чтобы не сломать нисходящий код, - это то, как вы хотите идти. Правильно написанный/проверенный код выявит проблемы, а затем вы сможете решить коренные проблемы. Лично, если 'User' и' Address' не являются 'Structs' (какие шаблоны говорят, что используют что-то вроде' User.Empty'), я бы позволил распространению ошибок и разоблачить их хорошо написанными модульными тестами. –