2011-02-09 70 views
2

讓我們回顧一些實體:建設靈活的和可重複使用的類層次

  • 公司;
  • 合作者;
  • 科長;
  • 下屬工人

有一些規則:

  1. 合作者可能是其中之一:銷售經理員工;
  2. 銷售和經理可能有下屬工人(第一條規則中規定的任何類型);
  3. 銷售,經理,員工可以有主任;
  4. 每個角色都有自己的工資 計算方法。

所以目標是創建可重用的類層次結構靈活的&。


讓我困惑的第一件事是「可以有」的短語。它應該作爲一個組合來實現嗎?如果說「可以有多少」,它應該是一個包含對象列表的作品?

我應該創建抽象類Collaborator,然後從它繼承3其他類型還是更聰明的方式?

將所有實體連接在一起並具有良好可重用組件的最佳方式是什麼?

+0

工資計算的規則是什麼?每個角色都有不同的角色,或者有一些共享薪資計算? – 2011-02-09 12:46:49

+0

我還要求澄清'下屬員工'和'員工'以更好地瞭解這種關係。 – SwDevMan81 2011-02-09 12:47:30

+0

@Steven Jeuris每個角色都有自己的薪水計算,但合作者類保持共享baseSalary。 – lexeme 2011-02-09 12:50:43

回答

0

"Can have"而事實上,它的後面"workers",告訴我這是一個"has a"關係(組成)與一個0到一對多的關係(所以列表,你提到可能是空的)

一個抽象類合作者似乎合理。

0

可以用UML表示爲(0 .. *)表示0或更多,是的,有對象列表的組合會好,使用集合而不是數組。

協作者是一個抽象類,因爲不會有協作者本身的實例。繼承3種類型的協作者是我猜測的最佳方式。

我必須補充一點,如果您的項目中只有一家公司,則需要實施Singleton設計模式。

關於工資使用虛擬方法並覆蓋它。

我希望這不是你的功課;)

+0

爲簡單起見,您可以只寫`*`而不是`0 .. *`。 – 2011-02-09 12:34:25

0

我想,這個問題的答案是主觀的,會根據自己的需要改變,但是這是我將如何實現它:

public class Company { 
    public List<Collaborator> Collaborators { get; set; } 
} 

public abstract class Collaborator { 
    public Collaborator(Company company) { 
     company.Collaborators.Add(this); 
    } 
    public virtual Decimal Salary(object value); 
    public Company Company { get; set; } 
} 

public class Sales : Collaborator { 
    public override Decimal Salary(object value) {} 
    public List<Collaborator> Subordinates { get; set; } 
    public Collaborator Chief { get; set } 
} 

public class Manager : Collaborator { 
    public override Decimal Salary(object value) {} 
    public List<Collaborator> Subordinates { get; set; } 
    public Collaborator Chief { get; set } 
} 

public class Employee : Collaborator { 
    public override Decimal Salary(object value) {} 
    public Collaborator Chief { get; set } 
} 

此代碼尚未經過測試。

0

我覺得這個問題制定得不好,設計可以通過添加小的額外信息來改變。

根據你寫的東西,我可能會考慮創建以下類(「 - 」號填列擴展):

 
Company 

AbstractCollaborator (Chief member, CalculateSalary() { return base + AdditionalSalary() }, abstract AdditionalSalary()) 
- Chief 
- AbstractLeader (List subordinates) 
-- Sales 
-- Manager 
- Employee 

處長就沒有首席集本身。我會盡量避免使用虛函數,並嘗試使用抽象函數。

另一種選擇是簡單地使用一個類。只有銷售人員或經理可以有下屬,這一切都很好,但在現實世界中,任何人都有下屬可能是必要的。任何類型的員工的功能可以簡單地由枚舉值指定。

這一切都很大程度上取決於你要去哪裏...