设计一个上传服务.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"时，他们会这样做。
最好的团队领导会向经验不足的成员解释他们的思维过程，帮助他们理解如何做出权衡，并使他们成为更好的开发人员。
如果你认为你的设计太复杂了，最好和领导核实一下。不要说"我怎样才能……"，而要说"我认为我们应该……"因为…"。优秀的管理者喜欢他们的团队成员表现出主动性，并且会更有动力分享他们所知道的。