标签为 ‘架构设计’
对象原则重于设计模式，分析方法重于对象原则，建议阅读体会。后面有功夫的话将对基本的分析方法进行详细阐述。 访问以下链接获取文档,或者访问我的SkyDriver共享目录获取文档。 面向对象原则概述： OO Design Principles Principles and Patterns 一些面向对象的设计法则 面向对象原则详解： The Dependency Inversion Principle The Interface Segregation Principle The Open-Closed Principle The Liskov Substitution Principle The Single Responsibility Principle The Granularity Principles The Stability Principles
同事发布一个在线查询的WebService，总是遇到麻烦，于是就去看看。稍微浏览之后，问题还没有定位，但发现了一个不合理的地方：将虚拟目录配置在长文件名之下，并且路径包含有空格。但同事说在这个版本下这样的情况好像是允许的，并且他已经指定成了短文件名，比如："C:Progra~1Micros~4WS”。 这让我想起了另一件事，老婆是计算机专业的老师，前几天晚上看到她在为《JSP基础编程》备课，讲义的一节是对JSP注释语法的讲解。她的讲义很详细，详细阐述了注释有多种，其中：<%– comment –%>中的Comment字符串是不被解释的，而<!– comment [ <%= expression %> ] –> 中则可以放入类似示例中的expression语句，并且会被解释的。 诸如此类的事例举不胜举，技术人员往往陶醉于模棱两可的细节中，更因为自己掌握了细节之间的差异、细节在不同的环境及系统之间的差异而沾沾自喜。 然而，在我看来，既然有相当一部分Web Server不允许路径包含空格，那么有何必非要使用一个带空格的长文件名，用~1、~4的方式指定更是自找麻烦，并且颇有奇技淫巧的意味。同样，注释就是注释，何必在里面包含逻辑？即使当时清楚自己的所为，也比将为以后的维护和其他人的理解带来麻烦，更何况这是对初次接触这个领域的学生所授的基础课程。 绝大多数技术人员却长期沉浸于此。看了很多花花绿绿的东西，从来不去想其中的思路和概念，而是将将这么一句挂在口头：“好牛啊”，更甚者如果是类似自己公司的软件，就立马准备照抄其中的某些“精彩之处”，并扬言曰“人家这么做自然有他的道理”。且慢，动手之前是不是应该考虑这两个问题：1、人家到底是怎么做的？2、他的道理到底是什么？3、这个道理是否对我们适用？4、我们既然是踩着人家向上爬，怎样才能做的更好，又依据什么样的道理呢？ ……。 不去思考，不愿总结归纳；脑袋里就喜欢塞满各种看似巧妙的东西，小脑壳就那么大，到底能塞进多少内容呢？错将技巧当技术，无疑于本末倒置，万望诸位同仁引以为戒。
看到一个有意思的站点(http://www.questpond.com/)，里面提供了多个方面的软件研发知识检查点。这是一个商业站点，据说是为求职者服务，帮助外国的求职者应对他们的未来公司，看来鬼佬也讲究“临阵磨枪，不快也光”。 当然，其内容可以作为我等自我检查知识掌握程度的一个参考。该网站内可以免费下载的检查列表有以下几个方面：项目管理、软件架构、网络、软件测试、Dot Net、SQL Server、C# & ASP.net、JAVA等，其中某些列表还提供了详细的应对答案:->。 下文是对软件架构的一部分翻译，供大家参考，以了解网站涉及内容的大致层面。 架构基础知识 1）阐述软件架构的定义； 2）阐述正在研发的产品或项目的架构； 3）讲解你在项目或产品研发中经常使用何种UML图； 4）讲解你曾经使用过哪些设计模式 5）阐述你在产品技术文档中一般包含哪些内容； 6）阐述不同的软件开发生命周期； 7）阐述企业架构的定义； 8）解释TOGAF（开发小组架构框架）； 9）解释OOA与OOD； 10）解释负载均衡的概念； 11）解释无状态负载均衡机制； 12）解释有状态的负载均衡机制； 13）解释Round-Robin（轮询调度）机制； 14）解释最小连接请求、加权分配请求及响应时间； 面向对象 1）什么是OOP； 2）面向对象编程对比传统功能编程的优点； 3）阐述面向对象的特征； 4）解释接口； 5）解释聚集与组合； 6）什么是抽象类； 7）抽象类和接口有何区别； 8）构造方法是否可以是私有的； ……
