如何使用链式 AddX 类型的方法从数据库构造对象层次结构来改进此设计?

发布于 2024-08-29 06:12:05 字数 1137 浏览 2 评论 0原文

目前,我正在我的应用程序中处理多层组合。我们从数据库中读取 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

难忘№最初的完美 2024-09-05 06:12:05

按照您在此处描述的方式,人们可以删除类 ProductLocationForecaster,但我猜它们会执行此处未显示的其他操作,因此不能已删除。如果不能更好地理解这些对象和类的语义,我就无法再为您提供帮助。我的一般建议是,您应该尝试为您的应用程序创建一个 UML-Object-Diagram对于一个简单的场景(没有太多的对象)。这可以帮助您发现模式并更好地理解对象的角色。

In the way you describe it here, one could just cut out the classes ProductLocation and Forecaster, 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文