Wie kann ich die Logik der Klassen- und Namenstechniken trennen?

Question

Dies ist für ein Mitarbeiteranrufsystem.

Ich habe 3 Klassen bisher: Person Manager und Manager-Team.

Die Person, die die Basisklasse ist, wobei Manager die Klasse ist, die mit der Klasse ManagerTeam auf Berechtigungen zum Erstellen neuer Mitarbeiter zugreifen kann.

Der Einfachheit halber werde ich einige der Personenklasse überspringen.

class Person 
{ 
    private string firstName; 
    private string lastName; 
    private string phone; 

    public string FirstName 
    { 
     get { return firstName; } 
     set { firstName = value; } 
    } 
} 

class Manager : Person 
{ 
    private string Position; 

    public Manager() : base() 
    { 
     Position = "Manager"; 
    } 
    /* 
    * later on maybe some sort of regulation for creating new manager 
    * or new person with acabailities here 
    */ 
} 

class ManagerTeam : Manager 
{ 
    private string Shifts; 
    private string On_Call; 
    string[] Employee_list = new string[5]; 

    /* 
    * maybe this should be turned into a funciton to insert all employees from 
    * "CreateNewEmployees" into the array. 
    */ 
    public ManagerTeam() : base() 
    { 
     /* 
     * this calls for another object being person to be assigned into 
     * an array for person. 
     */ 
    } 

    static MangerTeam CreateNewEmployee() /* change this is constructor */ 
    { 
     /* 
     * this assigns shift times and checks if on call and any data 
     * to an employee 
     */ 
    } 
} 

Ich bin verwirrt, weil ich davon denken sollte der Konstruktor sein sollten und welche die Funktion nur die Objekte der neuen Mitarbeiter in die Anordnung einer Liste der Mitarbeiter laden, die aus mehreren Gründen von Manager zugegriffen werden soll später implementiert. Später ist es das Ziel, eine Mitarbeiterklasse hinzuzufügen, und diese Mitarbeiterklasse kann Anforderungen akzeptieren und ablehnen. Diese Informationen werden auch bei der Entwicklung in das Managerteam einfließen.

Answer 1

Vererbung in OOP impliziert im Allgemeinen eine "ist-a" -Beziehung. In Ihrem Fall ist "ist ein" ManagerTeam ein Manager? Ohne den Zweck von ManagerTeam zu wissen, ist es schwer zu sagen, aber nur mit dem Namen würde ich nicht raten. Daher ist die Vererbung in Ihrem Design möglicherweise nicht die richtige Wahl.

In Bezug auf Konstruktor versus Methode, überlegen Sie, was erforderlich ist für ein gültiges Objekt. Wenn ein Manager benötigt, um Mitarbeiter ordnungsgemäß zu funktionieren, dann sollte das im Konstruktor sein, andernfalls ist eine separate Methode geeignet.

Answer 2

Der Schlüssel zu jedem Systemerfolg ist die Vereinfachung. Dies gilt insbesondere für Entitätsklassen, die die Grundlage bilden, auf der der Rest Ihrer Anwendung aufgebaut wird. Machen Sie es falsch, und das Projekt wird höchstwahrscheinlich fehlschlagen oder ewig dauern.

Die meisten Projekte, die ich mit anderen Entwicklern bei der Arbeit geteilt habe, tendieren dazu, überentwickelt und viel komplexer als wirklich benötigt zu sein, was Wartung und neue Verbesserungen schwierig macht.

In Bezug auf Ihr Beispiel IMHO Sie mit etwas einfacher und erhöhen die Komplexität versuchen könnte, wenn/falls erforderlich:

Reuse die Klasse Mitarbeiter für beide, normale Mitarbeiter und Führungskräfte und die Position Eigenschaft verwenden, um die Art der Mitarbeiter angeben.

public class Employee 
{ 
    private string firstName; 
    private string lastName; 
    private string phone; 
    //This could be turned into a class or a enum, e.g. Roles for more complex scenarios 
    private string position; 
    private string team; 
    private string shift; 

    //You can add a constructor if you want to make sure a position is always provided, but it would be better to handle this at the database level by setting the column as NOT NULL 
    public Employee(string position) 
    { 
     this.position = position; 
    } 

    ... 
} 

Die ManagerTeam Klasse wird der Kern oder Helfer-Klasse sein, dass Sie Ihre Daten einschließlich Ihrer Geschäftsregeln verwenden zu verwalten, sollte es nicht eigene Daten enthalten und rufen Sie einfach andere Methoden, zum Beispiel eine Datenbankkontext oder Arbeitseinheit, um Daten abzurufen:

public static class ManagerTeam 
{ 
    //You need to set this when the user signs in 
    internal static Employee CurrentEmployee; 

    //This method will return the full list of employees from your data source, you could use an IQueryable instead of the list so you can filter and make queries 
    public static IList<Employee> GetEmployees() 
    { 
      return db.Employees; 
    } 

    public static IList<Employee> GetEmployeeByPosition(string position) 
    { 
      return db.Employees.Where(x => x.Position == position); 
    } 

    public static IList<Employee> GetEmployeesByShift(string shift) 
    { 
      return db.Employees.Where(x => x.Shift == shift); 
    } 

    public static IList<Employee> GetEmployeesByTeam(string team) 
    { 
      return db.Employees.Where(x => x.Team == team); 
    } 

    public static void CreateEmployee(Employee employee) 
    { 
      // Only managers can add employees 
      if (CurrentEmployee.Position == "Manager") { 
       db.Employees.Add(employee); 
      }  
    } 

    ... 

} 

Wenn Sie einen Rahmen wie ASP.NET MVC oder WPF oder andere verwenden, könnten Sie diese Klasse ganz vermeiden und einfach alles in den Controllern behandeln, Aktionen, Viewmodels, etc ...

Answer 3

würde ich empfehlen Beenden Sie die Verwendung eines Mixin-Patterns, um dieses Problem zu beheben. Mitarbeiter zu erstellen ist eine Funktionalität eines Mitarbeiters, der ein Manager und ein Managerteam eine Funktionalität von Mitarbeitern ist, die Manager sind. So würde ich es bricht in den folgenden:

class Employee 
    { 
     private string firstName; 
     private string lastName; 
     private string phone; 

     public string FirstName 
     { 
      get { return firstName; } 
      set { firstName = value; } 
     } 
    } 

    interface IManager 
    { 
     Employee CreateNewEmployee(); 
    } 
    class Manager : IManager 
    { 
     private readonly Employee _employee; 

     public Manager(Employee employee) 
     { 
      _employee = employee; 
     } 
     public Employee CreateNewEmployee() 
     { 
      throw new NotImplementedException(); 
     } 
    } 

    class ManagerTeam : IManager 
    { 
     private readonly IEnumerable<IManager> _employees; 

     public ManagerTeam(IEnumerable<IManager> employees) 
     { 
      _employees = employees; 
     } 
     public Employee CreateNewEmployee() 
     { 
      throw new NotImplementedException(); 
     } 
    }