十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
如何分析.NET独有精巧泛型设计模式,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
“专业、务实、高效、创新、把客户的事当成自己的事”是我们每一个人一直以来坚持追求的企业文化。 成都创新互联公司是您可以信赖的网站建设服务商、专业的互联网服务提供商! 专注于成都做网站、网站设计、软件开发、设计服务业务。我们始终坚持以客户需求为导向,结合用户体验与视觉传达,提供有针对性的项目解决方案,提供专业性的建议,创新互联建站将不断地超越自我,追逐市场,引领市场!
虽然泛型出现已有多年,连Java都早已借鉴引入了泛型(虽然是语法糖),可是用泛型的编程思维方式并没有得到相应的普及。一方面是由于过去大量的Framework仍然是在非泛型时代写成的,另一方面泛型的设计模式没有得到发展,改变的时候该到了。
来举一个例子说明这两点。我们如果写过网络数据抓取的代码,应该熟悉这样的代码:
var request = WebRequest.Create("http://www.cnblogs.com/") as HttpWebRequest;
或者这么写,也是一样:
var request = HttpWebRequest.Create("http://www.cnblogs.com/") as HttpWebRequest;
大家可想过,为什么每次都要as一下?
类似的情况还有,比如做图像处理的弟兄会熟悉:
var bm = Image.FromFile("e:\\me.jpg") as Bitmap;
和
var bm = Bitmap.FromFile("e:\\me.jpg") as Bitmap;
我想过,但没想明白。上面两种写法,都是调用父类的工厂方法,实际返回了一个子类的实例。显然,即使不了解OCP,凭直觉也应该想到,父类的实现中不应该被子类所决定。写WebRequest和Image的前辈可能也觉得直接返回子类实例不妥,所以阴险地把方法签名的返回类型改成了父类。
虽然这种行径值得严重鄙视。但.NET程序员大都是人云亦云,照葫芦画瓢的好学生,所以这个问题多年了也没有修改。
理想的设计应该是这样:父类的每个子类,都有独立的工厂方法,返回其自身的实例。这样做法,在泛型出现前非常笨拙,得不偿失,但有了泛型,就可以精巧地实现。
以模拟Image类为例,Image和BitMap实现如下:
class Imagewhere T:Image , new() { public string Path { get; set; } public static T FromFile(string path) { return new T() { Path = path }; } } class Bitmap:Image { }
Image自身的工厂方法,就没有存在的必要了。
可以简单地测试一下:
var path = @"e:\me.jpg"; var bm = Bitmap.FromFile(path); ; Console.WriteLine(bm.Path); Console.WriteLine(bm.GetType().Name);
输出结果如下:
Path: e:\me.jpg Type: Bitmap
为了让大家更熟悉一下,再举一个实现数据结构中的二叉树作例子。
传统的树节点类,无论无论C/C++/Java都是类似这样:
class TreeNode { public TreeNode LeftChild { get; set; } public TreeNode RightChild { get; set; } public TreeNode Parent { get; set; } public int Value { get; set; } }
大家知道,二叉树又分好几种,AVL树、B树、红黑树等等。实现特殊的二叉树数据结构,势必要继承TreeNode。由于树节点的类型中,有类型为基类的成员,所以在子类操作这些成员时,往往也要强制转换类型,这比Image和WebRequest的例子,只在实例创建时转换类型还麻烦。
这就该泛型模式一显身手的好机会了,请看其父类型的实现:
///Type of the node. ///Type of the node value. class TreeNodewhere T:TreeNode where K: IComparable { public T LeftChild { get; set; } public T RightChild { get; set; } public T Parent { get; set; } public K Value { get; set; } }
之后,实现任何一种特殊二叉树结构,比如RBTreeNode代表红黑树节点,可以这样:
class RBTreeNode : TreeNode{ /// /// 树节点颜色,是否为红。 /// public bool IsRed { get; set; } public override string ToString() { return this.Value + "," + (this.IsRed ? "R" : "B"); } }
这个是AVL树:
class AvlTreeNode : TreeNode{ /// /// 节点的平衡度 /// public int Balance { get; set; } public override string ToString() { return "Balance: " + Balance + ", Value: " + this.Value; } }
不但完全符合OCP原则,而且再也不需要as来强制转换节点类型了。
这肯定不是我的首创,其实.NET Framework中已经不少这样的设计,比如IComparable
看上去也很简单吧,但是很多人思维还停留在面向对象语言刚诞生的阶段,还不习惯用这种设计模式。我认为这种写法足够典型和通用,足以得上一种设计模式,而且是.NET特殊优势,独特魅力。
说到设计模式,其实GOF提出的23种设计模式多年了,已经过时,出现了许多新模式(比如并发编程方面,参考Wiki Design Pattern)。旧有的模式中,有的已经包含在.NET语言特性中,有的模式实现方式已经改头换面。尤其在泛型出现后,许多模式的实现可以变得简洁许多,优雅许多。
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。