какая польза от создания свойства в отдельном классе для каждого объекта? - PullRequest
0 голосов
/ 16 ноября 2010

Я изучаю некоторую хорошую практику кода, поэтому я изучал некоторый код, кое-что, чего я не мог понять в нем.Он сделал свойство в отдельном классе для каждой сущности, как в userClass, у него есть свойство

  #region public properties

    private int uid;
    public int userId
    {
        get { return uid; }
        set { uid = value; }
    }

    private string uName;
    public string userName
    {
        get { return uName; }
        set { uName = value; }
    }

    private string pwd;
    public string password
    {
        get { return pwd; }
    //    set { pwd = value; }
    }


    private string uAddress;
    public string userAddress
    { 
        get { return uAddress; }
        set { uAddress = value; }
    }


    private string fName;
    public string firstName
    {
        get { return fName; }
        set { fName = value; }
    }

    private string lName;
    public string lastName
    {
        get { return lName; }
        set { lName = value; }
    }

    private string uPhone;
    public string userPhone
    {
        get { return uPhone; }
        set { uPhone = value; }
    }

    private string uMobile;
    public string userMobile
    {
        get { return uMobile; }
        set { uMobile = value; }
    }

    private int secretQuestion;
    public int securityQuestion
    {
        get { return secretQuestion; }
        set { secretQuestion = value; }
    }

    private string userAnswer;
    public string answer
    {
        get { return userAnswer; }
        set { userAnswer = value; }
    }

    #endregion

, и из класса бизнес-логики он использует свойство вместо непосредственного использования имени атрибута любой сущности, но я запутался, чтонужно ли создать свойство, подобное этому?

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

Ответы [ 3 ]

1 голос
/ 16 ноября 2010

Вы действительно спрашиваете, почему он использует свойства вместо открытых полей?

Поля - это детали реализации - они хранят данные, которые не должны быть предметом заботы внешнего мира.минимум для 99% типов.Свойства являются частью контракта, который тип имеет в отношении своего API - реализация соответствует типу.Другими словами, это вопрос инкапсуляции.Свойства могут быть выражены в интерфейсах, как абстрактные методы и т. Д., Именно потому, что они разделяют контракт и реализацию.

Кроме того, свойства упрощают привязку данных, отладку и различные другие вещи.У меня есть статья о том, почему свойства имеют значение , которая может оказаться полезной.

Сказав все это, эти свойства реализованы утомительно - и они не подчиняются .NETсоглашения об именах.Я бы написал их так:

public int UserId { get; set; }
public string UserName { get; set; }
public string Password { get; set; }
// etc
1 голос
/ 16 ноября 2010

Некоторые похожие вопросы:

Открытые поля и автоматические свойства

Свойство против открытого поля .

Дополнительновыше: на самом деле вы можете легко выбрать публичное поле или собственность самостоятельно.Намного проще понять, что:

(1) Name является свойством класса Person

(2) Speed является свойством класса Plane

(3) Empty является открытым полем класса String.Если вы говорите, что String имеет свойство с именем Empty, это действительно странно.И String имеет свойство Length, которое легко понять.

1 голос
/ 16 ноября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...