设计一个上传服务.OOP中的Helper/Utility类
本文关键字:中的 OOP 服务 Helper Utility 一个 | 更新日期: 2023-09-27 18:16:41
我刚刚大学毕业,加入了一家成熟的软件公司,并加入了一个18人的团队。
我的任务是编写一段代码,将生成的报告(报告a)上传到文件转储区域,如SharePoint。我们的应用程序现在生成许多报告(报告A到Z),但我的任务现在只做报告A。
几乎毫不费力,我知道我必须设计我的上传服务,允许报告(B到Z)在未来轻松使用我的服务,而不会有太多麻烦。
团队中的一位资深人士,告诉我做一个单独的助手/实用程序类来上传文件。
然而,我提出的设计涉及工厂设计模式,返回一个继承自Uploader抽象类的reporta Uploader,并调用UploadService文件。将来,Report B to Z可以简单地继承Uploader抽象类,并实现一个确定要上传的目的地的方法。
所以我很困惑,我真的想太多这个问题吗?我的设计错了吗?
如果不知道使设计正确的所有标准,就不可能说设计是"错"还是"对"。一般来说,团队领导应该比下级更了解这些标准(但并非总是如此)。还要记住"right"answers"optimum"是有区别的。
在商业环境中,经验丰富的开发人员经常在"好的"设计和"快速"解决方案之间进行权衡,而且这种权衡通常是隐含的。他们也学会了不信任复杂性。通常,当团队领导说"做X"时,他们会这样做。
最好的团队领导会向经验不足的成员解释他们的思维过程,帮助他们理解如何做出权衡,并使他们成为更好的开发人员。
如果你认为你的设计太复杂了,最好和领导核实一下。不要说"我怎样才能……",而要说"我认为我们应该……"因为…"。优秀的管理者喜欢他们的团队成员表现出主动性,并且会更有动力分享他们所知道的。