Это плохая практика для изменения переменной в методе? - PullRequest
1 голос
/ 15 апреля 2011

Какой стиль метода лучше? Как правило, плохая практика - модифицировать переменную в методе?

public class Person
{
   public string Name { get; set;}
}

//Style 1
public void App()
{
    Person p = new Person();
    p.Name = GetName();
}
public string GetName()
{
   return "daniel";
}

//Style 2
public void App()
{
    Person p = new Person();
    LoadName(p)
}
public void LoadName(Person p)
{
   p.Name = "daniel";
}

Ответы [ 5 ]

3 голосов
/ 15 апреля 2011

Бывают моменты, когда оба стиля могут иметь смысл.Например, если вы просто устанавливаете имя, то, возможно, вы выбираете первый стиль.Не передавайте объект в метод, чтобы изменить одну вещь, просто получите одну вещь.Этот метод теперь более пригоден для повторного использования.Думайте об этом, как о законе Деметры или о принципе наименьшего знания.

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

Любой подход может быть оправдан в разное время.

3 голосов
/ 15 апреля 2011

Я думаю, что код становится более понятным и читаемым, когда методы не изменяют переданные объекты. Особенно внутренние поля передаваемого объекта.
Это может быть необходимо иногда. Но в целом я бы этого избегал.

Обновлено на основе комментариев (хорошая точка)

1 голос
/ 15 апреля 2011

Я согласен с ответом Энтони.There are times when both styles may make sense.

Кроме того, для большей читабельности вы можете добавить функцию LoadName в личном классе.

public void App()
{
    Person p = new Person();
    p.LoadName(); //If you need additional data to set the Name. You can pass that as Parameter
}
0 голосов
/ 15 апреля 2011

Вы получаете доступ к данным, используя свойства, которые технически являются методами.Что вас беспокоит, так это свойство, обращающееся к iVar или внутренней переменной.Причина, по которой обычно запрещен доступ к iVar, заключается в том, что любой может изменять переменные без вашего ведома или без вашего разрешения, если через методы (свойства) вы можете перехватить сообщение при его получении или установке,или препятствуйте тому, чтобы это было прочитано или написано, таким образом это, как обычно говорят, является лучшей практикой.

0 голосов
/ 15 апреля 2011

Я согласен с Роном. Хотя ваш конкретный пример может быть немного надуманным для публикации, у меня будет публичный получатель имени и частный установщик. Передайте имя конструктору, и свойство Name будет установлено там, но впоследствии уже не может быть изменено.

Например:

public class Person
{
    public string Name { get; private set; }

    public Person( string name)
    {
        Name = name;
    }
}
...