Проектно-ориентированные проектные решения: классы с сохранением состояния или без состояния?

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

Что означает состояние объекта

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

Когда мы приходим к программированию и думаем о состоянии объекта в определенное время, это не что иное, как значение его свойств или переменных-членов в данный момент времени. Кто решает, каковы свойства объектов? Это класс. Кто решает, каковы свойства и члены внутри класса? Это программист, который написал этот класс. Кто такой программист? Все, кто читает эту статью, включая меня, кто пишет это. Все ли мы эксперты в принятии решения о том, какие свойства необходимы для каждого класса?

Я так не думаю. По крайней мере, так обстоит дело с программистами в Индии, которые входят в индустрию программного обеспечения, рассматривая зарплату и программирование как повседневную работу. Прежде всего это не то, чему можно научить в колледжах, как то, как работают другие инженерные дисциплины. Это требует опыта, потому что программирование, в отличие от других видов техники, на ранних стадиях больше похоже на искусство, чем на разработку. Инжиниринг иногда может иметь жесткие правила, но искусство не всегда. Даже после того, как я занимался программированием около 15 лет (извините, я тоже считаю свои дни в колледже в области программирования), мне все еще нужно много времени, чтобы решить, какие свойства необходимы для класса и как называется сам класс.

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

Классы сущностей / бизнес-объекты

Существует несколько имен, таких как классы сущностей, бизнес-объекты и т. Д., Присвоенных классам, которые представляют ясное состояние чего-либо. Если мы возьмем пример класса Employee, его единственная цель — сохранить состояние сотрудника. Что может содержать это состояние? EmpId, Компания, Обозначение, JoinedDate и т. Д … Я надеюсь, что на этом этапе не будет путаницы. Все согласны с тем, что этот тип класса должен быть с учетом состояния без особых аргументов, потому что этому учат в колледже.

Но как нам сделать расчет зарплаты?

• Должен ли CalculateSalary()быть метод внутри класса Employee?
• Должен ли быть SalaryCalculatorкласс, и этот класс должен содержать метод Calculate ()?
• Если есть SalaryCalculatorкласс:
  
  • Должны ли они иметь такие свойства, как BasicPay, DA HRA и т. Д.?
  • Или Employeeобъект должен быть закрытой переменной-членом в том SalaryCalculator, который вводится через конструктор?
  • Или следует  SalaryCalculator выставить публичное свойство Employee ( Get&Set Employeeметоды в Java)?

Классы Помощник / Операция / Манипулятор

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

• класс, SomethingCalculatorнапример: SalaryCalculator
• класс, SomethingHelperнапример: DB Helper
• класс,  SomethingControllerнапример: контроллер БД
• учебный класс SomethingManager
• учебный класс SomethingExecutor
• учебный класс SomethingProvider
• учебный класс SomethingWorker
• учебный класс SomethingBuilder
• учебный класс SomethingAdapter
• учебный класс SomethingGenerator

   class SalaryCalculator
    {
        public double Basic { get; set; }
        public double DA { get; set; }
        public string Designation { get; set; }

        public double Calculate()
        {
            //Calculate and return
        }
    }

    class SalaryCalculator
    {
        public Employee Employee { get; set; }

        public double Calculate()
        {
            //Calculate and return
        }
    }

    class SalaryCalculator
    {
        public double Calculate(Employee input)
        {
            //Calculate and return
        }
    }

    interface ISalaryCalculator
    {
        double Calculate(Employee input);
    }
    class SimpleSalaryCalculator:ISalaryCalculator
    {
        public virtual double Calculate(Employee input)
        {
            return input.Basic + input.HRA;
        }
    }
    class TaxAwareSalaryCalculator : SimpleSalaryCalculator
    {
        public override double Calculate(Employee input)
        {
            return base.Calculate(input)-GetTax(input);
        }
        private double GetTax(Employee input)
        {
            //Return tax
            throw new NotImplementedException();
        }
    }

    class SalaryCalculatorFactory
    {
        internal static ISalaryCalculator GetCalculator()
        {
            // Dynamic logic to create the ISalaryCalculator object
            return new SimpleSalaryCalculator();
        }
    }
    class PaySlipGenerator
    {
        void Generate()
        {
            Employee emp = new Employee() { };
            double salary =SalaryCalculatorFactory.GetCalculator().Calculate(emp);
        }
    }

    class Employee
    {
        public string Name { get; set; }
        public int EmpId { get; set; }
        public double Basic { get; set; }
        public double HRA { get; set; }

        public double Salary
        {
            //NOT RECOMMENDED 
            get{return SalaryCalculatorFactory.GetCalculator().Calculate(this);}
        }
    }