0

Бывает когда пишишь код и тебе требуется улучшить его читабельность, но не всегда ясно, правильно ли это или нет!

Так вот хочу узнать у Вас, нужно ли использовать рефакторинг при написание кода?!

Допустим такой код:

static string Desktop = Environment.GetFolderPath(Environment.SpecialFolder.Desktop);

Студия рекомендует использовать рефакторинг, то есть инкапсулировать поле (и продолжить использовать свойства)

После рефакторинга:

public static string Desktop1
    {
        get
        {
            return Desktop;
        }

        set
        {
            Desktop = value;
        }
    }

Теперь он возвращает функцию для Desktop,нужно ли использовать такой подход?

GooliveR
  • 1,979

2 Answers2

2

Ок, вы меня уговорили, перечислять все в комментариях не удобно, поэтому пусть будет ответом, несмотря на "холиварность" вопроса, средней степени тяжести.

Все поля должны быть приватными.

Это требование ООП, поэтому даже не хочу обсуждать. Если требуется предоставить доступ к полю уровня protected, public или internal, то использование для этого свойств обязательно.

Когда нужны private свойства?

В общем случае private свойства абсолютно бесполезны, т.к. они не могут ограничить доступ к полю - уровень доступа у них одинаковый, ниже уже некуда. Исключение составляют автоматические свойства, но их возможность ограничения доступа к полю связана не с уровнем доступа, а тем фактом, что имена полей не известны программисту, да и компилятор их генерирует только в момент компиляции.

Но один случай полезного применения приватных свойств все же есть - это вычисляемые свойства за которыми нет конкретных полей или наоборот - совокупность зависимых полей. Другой вопрос, что для этих целей можно использовать обычные методы, но тут уже нужно смотреть на семантику использования и сложность кода аксессоров.

Более подробно про преимущества свойств, когда их применять нужно, а когда не нужно можно почитать в ответе @VladD - Для чего нужны свойства?

В приведенном вами примере, куда более ценно - явно указать модификатор private перед полем. Это избавит читающего ваш код от необходимости вспоминать/изучать уровень доступа по-умолчанию для членов класса.

rdorn
  • 16,323
  • Я правильно понял что публичные свойства лучше не использовать в том же классе, где вызывается какой-либо метод который присваивает это свойство) ? То есть это лучше использовать через другой класс и уже от туда обращаться?! – GooliveR May 18 '17 at 20:36
  • @ArteS с чего вы это взяли? Публичное свойство также может иметь вычисляемые аксесоры или содержать логику валидации, почему бы к нему не обратиться в методе того же класса, если это следует из логики метода. – rdorn May 18 '17 at 20:39
  • в каком случае лучше не использовать аксессоры get set? И в каких даже очень требуется?! Поясните пожалуйста, хочу понять просто) – GooliveR May 18 '17 at 20:47
  • Давайте продолжим в Чате – GooliveR May 18 '17 at 20:48
  • @ArteS ок, сейчас допишу, или найду соседний ответ =) VladD кажется уже писал об этом подробно – rdorn May 18 '17 at 20:48
  • Все поля должны быть приватными - я бы не был столь категоричным. Например, если нужна производительность, то почему бы не сделать поля публичными? Пример – Alexander Petrov May 19 '17 at 09:29
  • 1
    @AlexanderPetrov я считаю, что лучше сознательно нарушать запрет, когда знаешь зачем, чем считать, что так можно делать везде. Понятно, что ради производительности, когда все уперлось именно в нее, и глобальные переменные с безусловными переходами задействовать не грех. Но тут ведь как - опытный и так знает когда без этого не обойтись и чем грозит, а новичку лучше обозначить границу, за которую ходить не надо, дорастет - поймет сам. Так что пока оставлю ответ как есть. – rdorn May 19 '17 at 12:19
0

Если вы используете это поле только внутри методов своего класса (а у вас оно приватное), то данная инкапсуляция не нужна.

Если вас интересует тема автоматического рефакторинга кода, то лучше взгянуть в сторону плагина для Visual Studio под названием Resharper. Он имеет бОльшую функциональность и благодаря нему новичку очень легко приучить себя писать хороший код.

Andrei Khotko
  • 5,035
  • 2
    Хм, но у автора до проведения авторефакторинга было всё-таки приватное статическое поле, следовательно только для "улучшения читаемости" не стоит инкапсулировать это поле в свойство, изменяя при этом уровень доступа для последнего. – Nikita May 18 '17 at 18:45
  • Я где-то вычитал что не рекомендуется использовать публичные статические поля, что для них нужно использовать публичные свойства с аксессорами get;set; хочу понять просто нужно ли оно или нет) – GooliveR May 18 '17 at 19:09
  • На примере у меня есть след код: foreach (var files in new DirectoryInfo(Desktop).EnumerateFiles("","")) но ведь правильнее же будет использовать публичное свойства например: foreach (var files in new DirectoryInfo(Desktop1).EnumerateFiles("","")) ?! Ваша точка зрения? – GooliveR May 18 '17 at 19:19
  • @ArteS у Рихтера хорошо написано, почему public и protected должны быть именно свойства, а не поля, это что касается технической стороны. Да и с точки зрения ООП - поля должны быть приватными, для соблюдения принципа инкапсуляции – rdorn May 18 '17 at 19:46
  • @rdorn, Правильное ли расположения с моим примером? – GooliveR May 18 '17 at 19:53
  • @ArteS Да, вы правы! Правильно использовать именно свойство (Desktop1), потому как используя свойство, гарантируется то, что перед тем, как получить/установить значение приватного поля, обязательно выполнится код соответствующего аксессора. А код аксессора обычно представляет собой некоторую логику валидации данных. Если что-то непонятно, могу привести пример – Andrei Khotko May 18 '17 at 19:56
  • 1
    @ArteS у вас исходное поле приватное (не указан ни один из модификаторов => по-умолчанию приватное) - в данном случае переход к свойству исключительно на усмотрение автора, лично я бы не стал менять, на читаемость это не повлияет никак, а время обращения, пусть и незначительно, но увеличится из-за обращения через дополнительный метод – rdorn May 18 '17 at 19:57
  • 1
    @rdorn, И пусть обращается дольше чем обычно, но ведь пусть будет правильно чем не правильно)) Доли секунды ничего не изменят. – GooliveR May 18 '17 at 20:22
  • @ArteS а в чем правильность? ограничения доступа это не дает, от ошибок не защищает, следовательно код ради кода, а вот это уже не правильно – rdorn May 18 '17 at 20:26
  • @rdorn - в данном случае не защищает, но тогда зачем вообще писать свойство, если можно использовать public - поле? – Andrei Khotko May 18 '17 at 20:40
  • @AndreiKhotko первый комментарий прочитайте, у автора в вопросе приватное поле, а про публичные поля я и не говорил, это зло по определению – rdorn May 18 '17 at 20:42
  • @rdorn я подумал, вы сейчас говорите в общем про свойства с пустыми аксессорами. Тогда да. Произошло небольшое недопонимание. – Andrei Khotko May 18 '17 at 20:57