我一直认为,通过使用静态等级/密码来创建依赖性是一种坏的形式,会产生问题。 紧凑的政变和单位测试。
我的情况是,我有一组没有国家与之有关联的ur平方法,只使用这种方法的输入论据开展行动。 我相信你熟悉这种方法。
过去,我会着手设立一个小组,增加这些方法,并从我的法典格中直接叫他们。
UrlParser.ParseUrl(url);
但是,等待一分钟,这又给另一个阶层带来依赖。 我不清楚这些公用事业类别是否坏,因为这些类别是无国籍的,而这种程度是上述固定类别和单一州的一些问题。 是否有人澄清这一点?
如果我把方法移至打电话的班级,那么,只有打电话的班级才能使用这种方法。 相称原则可能违反单一责任原则。
从理论设计的角度来看,我认为,尽可能避免“Utility”课。 他们基本上与固定班级没有区别(不过,由于他们没有国家,所以略为nic)。
然而,从实际的角度来看,我确实创造了这些条件,并鼓励酌情使用<>>。 避免使用班级往往繁琐,导致可维持的代码减少。 然而,我确实努力鼓励我的开发商尽可能避免在公益物中出现这种情况。
例如,就你而言,我感到乌尔尔巴勒斯尔。 ParseUrl(......)可能更好地作为班子处理。 参看BCL中的“System.Uri,这处理的是清洁、易于使用的统一资源抑制器的接口,该接口运转良好,并保持实际状态。 我更喜欢采用一种实用的方法,这种方法可以用来进行扼杀,迫使用户穿透镜,记住加以验证等。
只要不违反设计原则,就可使用。 在你使用核心框架类别时,将它们作为习惯使用。
这些班级的名称应当明确,合乎逻辑。 其实,它们只是“有用性”的 t,而是土著阶层不提供的新兴的ram。
采用推广方法等方法,也可将功能与“右”类相统一。 由于延期与通常延长期限的类别混在一起,这种延长可能产生一些混淆,而这种延长并不理想,但还是非常有用,可以制定更清洁的法典。
你们总是能够形成一种接口,并使用依赖性注射与实施这种接口而不是固定班级的班级。
问题是,是否确实值得努力? 在某些制度中,答案是肯定的,但在另一些制度中,特别是在较小的系统中,答案可能是没有的。
这确实取决于环境,也取决于我们如何利用这一环境。
公用事业班本身并不好。 然而, 如果我们以坏的方式加以利用,就会变得坏。 每一种设计模式(特别是单一州模式)都很容易变成反家长,而乌特产阶级也是如此。
在软件设计方面,我们需要平衡灵活性和简便。 如果我们再造一个只负责扼制操纵的长处:
=> 北方班,不好。 它给开发商造成错失。
这完全取决于具体情况。 如果你只是gon子,就会产生一个只包含单一责任的公用事业类别,并且只在单元或一层内私下使用。 之后,你仍然赞成。
我同意这里的其他一些答复,即,这是传统的单一州,它只保留一个州性物体的例子,要避免,不一定是实用的班级,没有邪恶的国家。 我也同意Reed的看法,即如果有可能的话,这些通用方法将归入一个类别,这样就有意义了,而且从逻辑上讲,人们会怀疑这种方法会居留。 我要补充的是,这些静态通用方法往往是推广方法的良好候选人。
确实,我确实试图避免这些现象,但是,谁正在打着......他们跳到每一个系统。 然而,在我所举的例子中,我将使用URL物体,然后暴露URL的各种属性(protocol、领域、道路和查询参数)。
同样,我建立了许多海关控制,以验证百分比、货币、电话号码等。 在这样做之前,我有一个具有所有这些规则的Parser公用事业类别,但是,仅仅在已经知道基本规则的网页上放弃控制权(因此只需要
我仍然保留着ser子级和这些控制hide这一静态类别,但广泛使用(在很容易找到的地方保留所有层)。 在这方面,我认为,使用公用事业类别是可以接受的,因为它使我能够适用“Don t Repeat You”,而我则从使用公用事业的控制权或其他物体的有色人种中受益。
以这种方式使用的班级基本上为(纯)高层职能的名称空间。
从建筑角度看,如果你使用纯顶级“全球”功能或基本(*)纯静态方法,就不会有差别。 任何利弊都同样适用于对方。
在全球(“浮动”)职能中使用通用等级的主要论点是编码组织、档案和目录结构以及命名:
import Acme:::Url; Url::parse(url) over import function Acme:::parse_url; parse_url();. Or you might prefer the latter.因此,这在很大程度上取决于你使用的语言和您的项目、框架或软件生态系统中的公约。
(*) 您
物体方法的主要好处是,你可以注射该物体,然后用不同行为加以不同的执行。 如果你不需要替换静态方法,就能够直接发挥作用。 如果:
您也可决定静态呼吁“现在足够了”。
即便是用静态方法开始,你也能够使其在以后能够注入/放大。 无论是通过使用功能/可召值,还是采用内部称为静态方法的小型包装类别。
只要你设计得好,他们就会被罚款(也就是说,你不必不时改变签字)。
这些通用方法往往不会改变,因为它们只做一件事。 问题在于你想把一个更加复杂的物体紧.到另一个物体。 如果其中一人需要改变或替换,如果你有高度的对等,则会更加困难。
由于这些通用方法取得了一定变化,我常常说,这不是什么问题。
我认为,如果你重复和重复使用同样的通用方法,那将是最糟糕的。
这一录像。 如何设计好的APIC,以及为什么要由Joshua Blach负责,这解释了在设计APIC(即你的实用图书馆)时要铭记的若干概念。 虽然他是一位公认的 Java建筑师,但内容适用于所有方案拟订语言。
很少使用这些工具,你想要把你能够进入你的班级的逻辑像样,以便他们成为公正的数据集装箱。
但是,与此同时,你确实可以避免利用,有时需要这样做。
在本案中,我认为它 s。
该制度是存在的。 网址:http://www.un.org。