Условно ограничить доступ к недвижимости

Question

Есть ли лучший способ ограничить доступ к свойствам Occupation и Employer?

Этот класс просто предназначен для сбора информации о занятости человека (потенциального клиента).EmploymentStatus может быть Employed, SelfEmployed, Unemployed, Retired и т.д.

Answer 1

Заставлять разработчиков устанавливать свойства в определенном порядке - опасный дизайн: он вводит интерфейс в заблуждение и допускает ошибки.

Вместо этого рассмотрите возможность сделать EmploymentInformation неизменяемыми объекты:

// Constructor for retired / unemployed people
public class EmploymentInformation(EmploymentStatus status) {}

// Constructor for self-employed people - we know their status
public class EmploymentInformation(string occupation) {}

// Constructor for people employed by others - we know their status
public class EmploymentInformation(string occupation, Company employer) {}

public bool IsEmployed { get; }
public string Occupation { get; }
public Company Employer { get; }

Answer 2

Что-то не так с простым возвратом null, если значение не установлено? Это довольно распространенная практика. Если Employer не существует, его значение равно нулю. Почему это null, возможно, не имеет значения. Кроме того, необходимо установить статус занятости в ctor самого класса.

Answer 3

Новый ответ:

Учитывая, что объект предназначен только для хранения данных о статусе занятости пользователей CURRENT, он все еще не прав.

Как сказал @Jeff Sternal, вы не должны вызывать devназначать параметры на основе определенного заказа.В случае, если объект должен быть сериализован / десериализован, вы можете получить много ошибок.

Вместо этого вы должны предоставить функцию проверки.Что-то вроде bool IsValid(); Когда вызывается этот метод, выполните проверку бизнес-логики, чтобы убедиться, что объект находится в приемлемом состоянии.Вы можете просто вернуть false, если нет, сгенерировать исключение (пожалуйста, не делайте этого) или отправить код состояния, объясняющий, почему объект в настоящее время недействителен.

Обычно вы отправляете данные вобъект, КОГДА вы проверяете объект, хорош перед сохранением.Вышесказанное является лишь одним из способов сделать это.Другие включают в себя наличие библиотеки бизнес-логики, которая полностью отделяет логику от классов данных (лично я никогда не понимал, почему вы это делаете, но многие клянутся в этом.).

Answer 4

Во-первых, почему возможно построить объект EmploymentInformation, если нет Employer?

Насколько это возможно, вы не должны позволять объекту быть построенным в недопустимом состоянии.Вы можете выразить эти ограничения в конструкторе вашего объекта, используя Guard Clauses или Code Contracts .

public class EmploymentInformation
{
    public EmoloymentInformation(Employer employerInstance)
    {
        if(employerInstance == null)
            throw new ArgumentNullException();
    }

Во-вторых, вы можете использовать NullОбъект шаблон, так что вам не нужно генерировать исключения.Просто создайте соответствующий класс для EmptyEmployer и верните их, как показано ниже.

        public Company Employer
            {
                get
                {
                    return IsEmployed ? _employer : Employer.Empty; 
// Employer.Empty is static property which return an instance of EmptyEmployer just like string.Empty.


    }

Answer 5

Если вы были строгими, вы можете утверждать, что безработный не имеет профессии или работодателя, поэтому объект-человек не должен обладать этими свойствами.Это приводит к чему-то вроде этого.

class Person
{
    public EmploymentStatus EmploymentStatus { get; set; }
}

class EmployedPerson : Person
{
    public string Occupation { get; set; }
    public Company Employer { get; set; }
}

Однако на практике с этой неумолимой объектной моделью будет неудобно работать, так как вам нужно будет знать, работает ли человек, прежде чем создавать экземпляр объекта.Также будет трудно выбрать между занятым и безработным, так как вам придется создавать новый объект и копировать все по всему.

Клиническое различие не стоит.Я думаю, что столь же правильно и на самом деле более логично спрашивать безработного, кто является его работодателем, и чтобы он отвечал «у меня его нет», а не был в состоянии задать вопрос в первую очередь.

Для меня это был бы более гибкий класс.

class Person
{
    public Person()
    {
        this.EmploymentStatus = EmploymentStatus.Unemployed;
    }

    public void Hire(Company employer, string occupation)
    {
        this.Occupation = occupation;
        this.Employer = employer;
        this.EmploymentStatus = EmploymentStatus.Employed;
    }

    public void Fire()
    {
        this.Occupation = null;
        this.Employer = null;
        this.EmploymentStatus = EmploymentStatus.Unemployed;
    }

    public EmploymentStatus EmploymentStatus { get; private set; }
    public string Occupation { get; private set; }
    public Company Employer { get; private set; }
}

Answer 6

Это выглядит неправильно с логической точки зрения.

Объект называется "EmploymentInformation" и имеет свойство "EmploymentStatus"

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

Если что-то из этого является правдой, то мне кажется, что вы можете иметь Занятие, но по какой-то причине иметь EmploymentStatus чего-то вроде "NotEmployed".

В конце концов, давайте посмотримизначально создается запись, где используется EmploymentStatus.Затем в дальнейшем статус меняется на «NotEmployed». При следующей загрузке объекта вы потеряете данные.

Answer 7

Я не имел никакого опыта в этом, но где-то, что я хотел бы рассмотреть, находится в Code Contracts.

Посмотрите эти ссылки:

http://social.msdn.microsoft.com/Forums/en/codecontracts/thread/1ca2d371-4b85-479d-9e00-64c84e372f02

http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx

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