在一个项目中,我有以下阶级关系。 Employee
和Client
与Company
具有组合关系。所以实现如下。
class Company
{
private Employee _Employee {get;set;} // private fields as composition
private Client _Client {get;set;}
public Company()
{
_Employee = new Employee();
_Client = new Client();
}
public AddEmploees() //Employee objects are controlled by Company
{
//
}
public DeleteEmploees()
{
//
}
public AddClients() //Client objects are controlled by Company
{
//
}
public DeleteClients()
{
//
}
}
class Employee
{
string Name {get;set;}
int ID {get;set;}
string Address {get;set;}
string Department {get;set;}
DateTime DOB {get;set;}
private Employee() // constructor private
{
}
}
class Client
{
string CID {get;set;}
string Name {get;set;}
string Type {get;set;}
DateTime StartDate {get;set;}
string Address {get;set;}
private Client() // constructor private
{
}
}
当我想在UI上显示client
/ employee
详细信息时,DataService
应返回Company
个对象,而不是返回Employee/Client
个对象这种关系就是构成。因此,我可以在GetDetails()
中使用DataService
之类的方法,然后从数据库中获取所需的详细信息,以便为Employee
和Client
的属性进行分配。但现在问题是,我将无法访问_Employee
对象的私有字段(_Client
,Company
)来设置属性的值,如下所示
public Company GetDetails()
{
Company company = new Company();
string selectStatement = "SELECT...";
// Get data from DB
company.client.name = rdr["name"].value; // This is not possible.
.
.
.
}
虽然我没有什么想法来解决这个问题但是它们中的任何一个似乎都不适合这种阶级关系(构成)或违反关注点分离原则。感谢你在这方面的帮助吗?
答案 0 :(得分:1)
看起来你想要使用
为了实现相互可见性(又名C ++ friend class
),您可以使用
而不是私人公开。这将允许r / w访问其他对象的属性。 Microsoft也大量使用它(内部类,内部命名空间,参见例如http://referencesource.microsoft.com/#PresentationFramework/src/Framework/MS/Internal/Data/CollectionViewGroupInternal.cs)所以只要它有帮助它就不是禁止的设计实践
答案 1 :(得分:0)
您可以通过从Company对象本身而不是从外部调用GetDetails()来解决您的问题。像这样:
class Company
{
// other class features
public static getDetails(params) // params are there as a filter (if needed)
{
// connect to DB and get the data...
//
// here you can access private members of Company
// return array of companies (or a single company)
}
}
我觉得这个解决方案在OO意义上要好得多。 Class Company依靠自身通过静态方法获取数据。在获取实例之前,您不需要实例化COmpany。而且更多 - 私人数据得到很好的保护,外部世界也看不见。在您的解决方案中,即使您可以从外部访问私有成员,也会破坏封装,但这并不好。
我还会重新考虑使用组合来存储客户和员工,因为他们与公司的自然关系较弱。如果一家公司“死亡”,那么definitelly并不意味着其员工也会死亡。