Rya*_*sen 1 c# api-design protected internal
我在大约12岁的开发团队工作,我们构建了一套合理的API,我们仅在内部严格使用.通常,所有类和接口都是公共的,因为这就是它们的完成方式.我经常考虑将一些构造函数设置为内部的价值,以便API的消费者(尽管是内部的)必须使用工厂或我现在想不到的其他一些原因.
这是你和你的团队练习的东西吗？
这对您的单元测试有何影响？你是否发现通过它的工厂对一个类进行单元测试是可以的,还是通过像PrivateObject这样的东西来访问构造函数？
答案是肯定的; 我当前的项目只有一个开发人员正在处理它 - 我 - 然而我仍然使用可见性和其他访问修饰符,以及必要的更复杂的设计模式.原因如下:
如果您允许,编译器可以成为您实施良好设计模式的最佳工具之一.让一切都公开可能会引起很多麻烦,当你必须维护一个物体时,它在程序执行过程中的正常状态是面向对象的,相当于一个人在手术台上生活,胸部裂开,每个人知道他从他的孩子到他的电器公司在他的重要器官中四处寻找让他做他们想做的事.添加另一只手或移除一只手可能导致患者心脏骤停.
代码应该是自我记录的.被标记为内部的类或类成员意味着它应该是; 如果一切都是公开的,你不知道在与对象接口时是否有任何你不应该触摸的东西.再次,你让你的病人坐在手术台上,突然间有一个新人进来,抓住肝脏,然后"嘿,这是做什么的？".物体应该动摇它们的手,被告知做某事并放手去做,除了它们之外,任何人都不关心它们的肝功能.
代码应该由您的子孙后代维护.这与前两个规则有关,但基本上,有人应该能够打开你的代码库,找到入口点并追踪基本的执行流程,同时查看沿途使用的对象并确定它们的一般形式和功能.回到我们的手术台上,让我们说五年后有人走进这个场景; 一个男人在桌子上劈开,他的内心里有50个家伙.它看起来不像他见过的任何礼貌的社交风俗; 它可能看起来最像是一种仪式性的人类牺牲,大多数人遇到这种情况时的第一直觉就是奔跑.
然而,硬币的另一面是,为了自己的利益而实施的设计模式通常是非常糟糕的事情.一旦你大学毕业并获得第一份工作,没有人真正关心你知道如何实施战略模式,你不应该在第一次机会时这样做.每种模式都有一系列适用的环境.如果您是一名医生,您是否会对下一位走路的病人进行血管成形术,只是说你能够做到这一点？