【问题标题】:Interview question on Class design类设计面试题
【发布时间】:2011-03-28 09:46:37
【问题描述】:

最近我参加了一次面试。有人问过这个问题。

这就是场景。

我们有两种类型的员工。正式员工和合同工。 正式员工将在月底按固定基准支付工资。 合同员工将根据他们的工作小时数每周获得报酬。

经理将被分配给这些员工进行监督。 经理可能有固定和合同雇员。

此应用程序将计算这些员工的工资。

他们让我想出针对这种情况的班级设计。

面试官希望我的回答是什么? 非常感谢您向这个方向提出建议。

【问题讨论】:

  • 建议您发布您尝试设计的课程......
  • 可能面试官更关注你提出的问题,而不是你给出的课堂布局。
  • Captain Obvious' 的举动:他们要求class design,所以他们希望看到你将如何为这个“系统”设计类关系。
  • 最近我参加了一个面试,他们让我做一些类似的pre工作。 “面试官希望我给出什么答案?”或者他期待什么分析器

标签: c# class-design


【解决方案1】:

他们正在测试您是否了解良好 OO 设计的一些基本原则。具体来说,他们似乎在寻找:

  1. 对多态性的理解(通过在抽象基础级别使用每个 Employee 的功能)
  2. 了解专业化(通过扩展 Employee 基类的功能以产生不同的行为)

【讨论】:

    【解决方案2】:

    这是一个考验你的问题,如果你了解关注点分离(计算员工的工资不是员工本身的责任),并看看你是否了解抽象性和多态性:那里是(目前)计算工资的两种不同方法。您可以实现某种策略设计模式来执行计算,以便算法的每个实现都在单独的类中指定。这有助于可维护性和扩展性(如果需要另一种算法)。

    public class Employee
    {
        public bool IsContractEmployee
        {
           get;
           set;
        }
    }
    
    public class WageCalculator
    {
    
        private abstract class WageCalculAlgorithm
        { 
            public virtual decimal Calculate( Employee emp )
            {
                 // regular calc goes here
            }
        }
    
        private class ContractorCalculator : WageCalculAgorithm
        {
            public override decimal Calculate( Employee emp )
            {
                // contractor calc goes here
            }
        }
    
        public static decimal CalculateWageFor( Employee emp )
        {
           if( emp.IsContractEmployee )
                return new ContractorCalculator().Calculate(emp);
           else
                return new WageCalculAlgorithm().Calculate(emp);
        }
    }
    

    【讨论】:

    • 我不确定这是否是他们正在寻找的答案。我认为他们正在寻找多态性
    【解决方案3】:

    以下可能是其中一种设计

    设计 1.

    public class Employee
    {
       public bool isContractEmployee
          { get; set;}
    
       public abstract float CalCulatePayroll();   
    }
    
    
    public class FullTimeEmp : Employee
    {
       public override float CalCulatePayroll()
       {
       }
    }
    
    public class ContractEmp : Employee
    {
      public int NoofHR
          {get; set;}
    
      public override float CalCulatePayroll()
       {
           sal = nohr*money;
       }
    }
    

    设计 2.

    public class employee
    {
      public bool isContractEmployee
      { get; set;}
    
      public int NoofHR
      {get; set;}
    
    
      public  float CalCulatePayroll()
      {
        if(this.isContractEmployee)
        {
          //calculate sal on based hr
        }
        else
        {
          //calculate regurlare sal
        }
      }
    }
    

    【讨论】:

    • 设计 1 对我来说没有多大意义。为什么要有布尔标志和继承?
    • @Jules - 仅用于在拨打电话时检查员工是合同工还是全职员工
    • 我不知道在 C# 中是否不鼓励这样做,但是检查实例是否足够? if(empInst is FullTimeEmp){}
    • 检查实例类型或测试布尔值是反 OO 的(如果它有一个 setter 则更糟):使用多态 CalculatePayroll() 方法。 CalculatePayroll() 可以简单地忽略全职员工的小时数。 Design1 很好,除了 isContractEmployee 是 a) 不需要和 b) 不好的风格。
    • 我想你还想要一个 Manager 类和实例来保存全职和合同雇员的列表,然后它的 CalculatePayroll() 方法应该返回所有下属的总数(加上自己,可选)。 Manager 可以是 FulltimeEmployee 的子类(如果需要其他特殊方法,可以使用 mixin)。
    【解决方案4】:

    面试官可能希望您尽最大努力提出您认为解决问题的解决方案。

    他还希望您解释您在提出解决方案时所做的一些决定。

    终于希望您自己想出解决方案,而不是在互联网论坛上寻求解决方案。

    技术上很难说出他的预期,因为我们不知道你要争取什么级别的职位。如果您打算从事第一份开发人员工作,他可能没想到您会得到正确答案,而只是想看看您解决问题的方法是什么样的。

    【讨论】:

      【解决方案5】:

      我会走这条路:

      public class Employee
      {        
           public abstract int CalculateSalary();
      }
      
      
      
      public class RegularEmployee : Employee
      {
          public int NumOfWeeklyHours { get; set; }
          public int CalculateSalary()
          {
                  // TODO: Implement
          }
      }
      
      public class ContractEmployee : Employee
      {
          public int FixedBasis { get; set; }
      
          public override int CalculateSalary()
          {
              // TODO: Implement
          }
      }
      
      public class Manager
      {
          public List<Employee> InChargeOf { get; set; }
      }
      
      public class PayRoll
      {
          public int CalculateSalaries(List<Employee> le)
          {
               return le.Sum(e => e.CalculateSalary());
          }
      }
      

      【讨论】:

        猜你喜欢
        • 2013-10-23
        • 2011-12-27
        • 2011-09-28
        • 2011-08-25
        • 1970-01-01
        • 1970-01-01
        • 2012-12-13
        相关资源
        最近更新 更多