如何使用链式 AddX 类型的方法从数据库构造对象层次结构来改进此设计?
目前,我正在我的应用程序中处理多层组合。我们从数据库中读取 ProductLocations
数据并将其放入 Solver
对象中。在另一个查询中,我们读取连接到产品位置的多个 SalesActivities
,这些位置需要放置在正确的 ProductLocation
对象深处的对象中。我最终得到了链式 AddSalesActivity
方法,如以下代码所示。
多年来,我在我工作的许多应用程序中都看到过这种结构。有时甚至使用更长的链条。我今天在思考这个问题,这听起来像是微妙的重复。关于处理这个问题的不同方式有什么想法吗?有没有办法提出更好的设计?
class Solver{
List<ProductLocation> productLocations;
public void ImportSalesActivities{
//foreach sales activity read find the correct productLocation
//Call productLocation.AddSalesActivity)
}
}
class ProductLocation{
Forecaster forecaster;
public void AddSalesActivity(SalesActivity activity){
forecaster.AddSalesActivity(activity);
}
}
class Forecaster{
SalesActivityResolver resolver;
public void AddSalesActivity(SalesActivity activity){
resolver.AddSalesActivity(activity);
}
}
class SalesActivityResolver{
List<SalesActivity> resolvedActivities;
public AddSalesActivity(activity){
//update resolved activities based on complicated criteria.
}
}
Currently, I am dealing with multiple layers of composition in my application. We read data from database for ProductLocations
and put them into a Solver
object. In another query we read multiple SalesActivities
connected to product locations which needs to be placed in an object deep within the correct ProductLocation
object. I end up with chained AddSalesActivity
methods as in the following code.
Over the years I have seen this kind of a structure in many of the applications I worked. Sometimes even with longer chains. I was thinking about it today and this smells like a subtle repetition. Any ideas on a different way of handling this? Is there a way to come up with a better design?
class Solver{
List<ProductLocation> productLocations;
public void ImportSalesActivities{
//foreach sales activity read find the correct productLocation
//Call productLocation.AddSalesActivity)
}
}
class ProductLocation{
Forecaster forecaster;
public void AddSalesActivity(SalesActivity activity){
forecaster.AddSalesActivity(activity);
}
}
class Forecaster{
SalesActivityResolver resolver;
public void AddSalesActivity(SalesActivity activity){
resolver.AddSalesActivity(activity);
}
}
class SalesActivityResolver{
List<SalesActivity> resolvedActivities;
public AddSalesActivity(activity){
//update resolved activities based on complicated criteria.
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
按照您在此处描述的方式,人们可以删除类
ProductLocation
和Forecaster
,但我猜它们会执行此处未显示的其他操作,因此不能已删除。如果不能更好地理解这些对象和类的语义,我就无法再为您提供帮助。我的一般建议是,您应该尝试为您的应用程序创建一个 UML-Object-Diagram对于一个简单的场景(没有太多的对象)。这可以帮助您发现模式并更好地理解对象的角色。In the way you describe it here, one could just cut out the classes
ProductLocation
andForecaster
, but I'm guessing they do other things not shown here and can therefore not be removed. I cannot help you anymore without a better understanding of the semantics of those objects and classes. My general advice would be that you should try to create an UML-Object-Diagram of your application for a simple scenario (not too many objects). This can help you to discover patterns and better understand the roles of your objects.