- 博客(5)
- 资源 (1)
- 收藏
- 关注
原创 有没有搞错,新书的帖子没有一个关注。晕~~~
喜欢的朋友赶紧帮忙支持一下吧! http://topic.csdn.net/u/20071202/16/3ce7c495-cbe3-4915-9da6-b301434ef852.html
2007-12-29 11:38:00 619
原创 关于通用软件框架
术语框架在软件工程中被定义为从相同类型的应用中挖掘出的可复用的体系结构。问题是,相同类型的应用这一限定范围在面对现实世界时往往表现出超出原定预期的多样性。虽然仍然可称作相同类型,但新的应用很容易便在不经意间提出某种超越已有框架能力的需求。一旦出现这种情况,用户通常便踏入了修改扩展旧有框架的泥潭。他们很快发现,即使拥有原框架的源代码,新功能也很难被融洽的添入到框架中。旧有的结构很容易就被修改得面目全
2007-10-01 14:16:00 1329
原创 BOS设计缘由(三)
1.4 问题4和通用软件框架 到目前为止我们已经通过组件技术和一个组件管理器来为例程1-1大幅提升了复用性,并且这种复用性还可以在运行期体现出来。遵循这种方式,任何程序的绝大部分代码都可以被剥离为组件,从而使项目呈现出更佳的可复用结构。你也许想立即宣布我们已经发现了软件设计的诀窍—以组件和组件管理器作为基础的通用解决方案。但是,别忘了我们还有问题列表中的第4项。这最后一个问题告诉我们
2007-09-29 21:28:00 879
原创 BOS设计缘由(二)
1.3 更好的组件解决方案 使用组件之后,我们可以有效地解决问题列表中的1至3。但是,如果将想像稍作深入,我们会发现事情还能做得更好。假设例程中的Device类有多种绘图风格,那么我们也许会想让最终用户能够在运行期选择不同的风格,或者说是能够动态切换。为Device添加不同的函数(方法)也许是一条途径,但这不仅改变了Device的原有设计,并且也不是一种具备扩展性的方式。
2007-09-29 21:14:00 855
原创 BOS的设计缘由
让自己的工作得到复用,是每一个开发者,尤其是身处设计层次的有经验的开发者的共同心愿。本文就从复用性入手展开讨论,引申出BOS的设计缘由。 1.1 问题观察下述代码(C#),试着找出其复用性不佳之处: interface Shape {…}class Rectangle : Shape{…}class Circle : Shape {…}class Dev
2007-09-28 16:03:00 1053
BOS组件系统
2007-09-08
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人