gdpglc
- 浏览: 92662 次
- 性别:
- 来自: 长春
-
最新评论
-
masuweng：
:i总结的很好dea:
客户需求及骨头与肉的分工方法 -
夜神月：
DAO这个东西想象很美丽
Dao的作用 -
eyesmore：
"比如某连接池中有2个连接对象。有两个线程分别占用了 ...
数据库连接池死锁的原因和处理方法 -
gdpglc：
呵呵... 这例子很有启发。我说的情况是对已有对象加入新功能时 ...
OO的环境下，需要控制对象 -
悲剧了：
比如在web开发里，登录用户信息存放到session里面，需要 ...
OO的环境下，需要控制对象
文章列表
OO和GOF设计模式的关系
- 博客分类：
- 灵台渐明
OO本身是一种软件的构造范型。它本身的分解形式，使得软件可复用、可扩展。
OO本身并不要求应用GOF设计模式。
但OO在某些情况下，直观的OO表达，仍就为软件引入了不好的因素比如：两个对象需要用到一个算法。这时会产生重复逻缉，不能应对变化，类爆炸，不易修改和维护。这时就需要一些方法来达到某种设计目的。
这时：需要自已想办法，GOF设计模式是可选途径之一。
软件必然体现领域模型。
对于面向过程的软件是以数据和过程拆分开了的型式体现。
面向对象则是将数据和过程放到一起，这样能和领域在表式上采用类式的形式。
对于编缉器类软件，编缉器本身必须能表达被编缉的数据，所以编缉器本身就以一种特殊的形式体现了领域。因此对于这样的软件，可能只在编缉结束时，才把数据写到自定义的领域模型中。
用自定义的类来体现领域，是一种理想的领域表达方式。对于一些软件来说，可能做不到，或不需要这么做。比如显示系统目录的程序，用jtree来表式目录树就行了，不需要再自定义一套类。而对于基于数据库的软件比如：spring+mvc+orm，可以有领域对象，但为了避免实体对象和db技术 ...
Spring带来了什么？OOD学而无用
- 博客分类：
- 灵台渐明
2年前曾发过一个贴子被评为新手：
http://www.iteye.com/topic/865387
终于有机会使用spring了，也用了一年了，再谈谈现在的感想，是否还会评为新手呢？
目前我接触到的spring功能包括：
IOC 构建分层关系：
具体指 action->service->dao ...
switch 最后应加上break，由此想到的
- 博客分类：
- 灵台渐明
如果switch中的每个case都加了break语句，最后一个case要不要加呢？
从逻缉上看是没有差别的，但今天遇到一个情况，我同事改我之前写的一段代码，直接在switch中又加了一个新的case，而原来的最后一个case没有加上break，这就导致了错误。
因此，在写switch时，最后加上一个对逻缉没有影响的break是有意义的。
就象我之前写了一个单粒的类，没有把构造设为私有，我同事直接new来用，导致了一个奇怪的错误，查了许久。
由此可以想到：java的访问控制和spring的依赖注入（分层注入），都起到了可见性限制的作用，用好这些内容，对软件开发能起到很大的作用。
效率低下的加班的结果就是没有质量的产品
- 博客分类：
- 灵台渐明
如果公司有事没事都要加班，这样的害处是很大的。它会导致软件没有质量可言。
最根本的问题是：对于管理和设计人员，由于没有人力成本的约束，再差的软件解决方案也敢用，因为可以靠加班进行补偿，然后应付了事。这样就造成了对软件设计的不重视，从而也不重视软件人才。
随意的解决软件中的复杂问题，是不会产生好的软件的。 不重视软件人才，是不可能形成优良的技术团队的，没有好的团队是不会产生好的产品的。
这样到有一个好处，大部份人员是可以随意更换的（因为人员的技术不重要），只要能招来愿意加班的人就行。
做正确的事和正确的做事的区别
- 博客分类：
- 灵台渐明
记得几年前看 <<UML与模式应用时>>看到这样一句话:
分析和设计可以概括为：做正确的事(分析)和正确地做事(设计)。
当时 "做正确的事" "正确的做事" 没看明白. 这两天再看这本书,还是没看明白.昨天偶尔看到一本讲管理的书上说 领导要"正确的做事" 部门主管要"做正确的事"突然明白了这句话.
所谓做正确的事,即为不做不正确的事。这是要求做事的人要有区分正确的事和不正确的事的本领。这对于软件需求分析是很重要的，如果不能找到满足用户需求的软件功能，花再多的精力做出的软件也是无用的。 ...
js界面组件，可以通过组合jquery插件形成。界面的状态数据由控件自已保持。例子就是之前实现的，右边widget例表拖到左侧widget例的功能。例表的顺序、widget状态都是由jquery的sortable和draggable的使用。
有的界面可以不使用现成的，完全自已实现，比如tab页。这时把当前tab记录在变量中，用来协调tab的显示是一个办法。
从上边的例子，说到交互式编程就会想到mvc。我认为，对于以上例子可以认为是没有模型的。在软件实现时，如果没有应用数据则不需要模型。
java调用Aix的Shell脚本时注意
- 博客分类：
- 灵台渐明
平台:aix 5
jdk:jdk5_aix_64
Process的waitFor方法是否完成和process的输入输出流的ready()方法返回值的关系可以是任意的，包括：
调用返回前 false
调用返回前 true
调用返回后 false
调用返回后 true
OO的环境下，需要控制对象
- 博客分类：
- 灵台渐明
对象已经存在，但没有你需要的功能。这时需要在已有对象的基础上编写逻缉，这样的逻缉作为控制逻缉存在是合适的。
比如：String的 非null非空串判断
又如：调用别人提供的webservice API，一样存在类似的情况。
这说明，在现实的OO编程中，还是需要一部份逻缉是独立存在的，而它相关的数据不是和它在一个地方的。
这样的逻缉，因为不能随着对象的出现而出现，因此可能会写死到业务逻缉中，从而形成重复代码。
软件中的Helper或Util类就是用来放这种逻缉的地方。可以在任意位置使用。
浅析领域、领域模型、软件、OO
- 博客分类：
- 灵台渐明
也许这是高深的话题，但在这上边我有一些心得，写在这里与大家分享，高识之士万误见怪。
内容：
1.领域、领域模型、软件
领域是软件所涉及的问题空间。这话太不好懂。其实就是软件所解决问题的相关环境。比如：一个图书管里系统A，一定会涉及图书馆本身的内容。比如：书、读者、借书卡、书架、等。
领域的内容就是领域内存在的事物即领域对象。按需要抽取领域内的信息，即可得到领域模型。通常可以用类图表示。
我觉得领域是一种存在。可以是客观存在，也可能是人为创造出来的，比如：顶蘑菇中的马力。
软件必然体现领域
因为，软件解决的问题是以领域为基础的。比如说：图书管理系统中一定会涉及书这个概念。
唯物论中有物质 ...
领域是需求生存的环境。
领域也可被称为：问题空间、问题域。
领域的重要特性是：存在性。也就是说，它是存在的，且必须存在，并具有一定的稳定性。
但领未必是客观存在，有的邻域是人为创造出来的。比如：超级马力游戏。这个领域是人为创造出来的，但是当创艺完成后，会具有一定的稳定性。
领域的构成：和需求相关的事物（领域对象）。它具有属性和行为。因此可以用类图来表示领域模型。
因为领域的存在性，因此可以直接依据它设计软件的对应部份。
软件在开发时，会创造出一些对象用来实现功能。这样的对象不作为领域对象看待。比如IO库中的输入流和输出流对象，用来读写数据源。数据源可以作为领域对象看待。因为的确存在实际的 ...
用户原始需求与需求的展开
- 博客分类：
- 灵台渐明
需求可以分为业务需求和软件功能需求。
业务需求来自于用户领域。
软件功能需求，是由用户的业务需求、用户的直接意见、当前的软件技术、成本共同决定的。
业务需求和软件功能需求，用户可能会直接给出。但通常有模糊不清和不完整的地方。这时需要分析人员进行展开。展开时不明确的地方将它明确、不完整的功能需要补全。
展开时要尽量和用户确认，以避免用户有不同意见。
开发工作不必等需求完全展开再进行，以经明确的部份可以和需求分析同时进行开发。
面向对象编程的目的和起因
- 博客分类：
- 灵台渐明
面向对象编程的目的不是造出完美的对象，而是造出符合要求的软件。
面向过程的方法是将数据和步骤分开的。这是一种计算机的思维模式。这样会对数据和操作分开进行思考，这样忽视了数据和操作的相关性。
数据和操作是关系密切的。如果将数据和数据上的操作一同思考，是更加合理的，这自然形成了对象的概念。我想，这是面向对象方法的起因之一。
面向对象编程 vs 面向过程编程
- 博客分类：
- 灵台渐明
面向过程编缉是最容易让人理解的编程方式。将数据与逻缉分开，逻缉本身就是一些步骤。
面向对象支持：封装、继承、多态
封装：
面向对象的编程方法，要求把数据和数据相关的操作放到一个对象中，从而在语言层面上， ...
Axis1.5.5的效率问题
- 博客分类：
- 灵台渐明
Axis1.5.5的服务端如果采用Pojo的形式，则由于使用了java.beans.Introspector 处理服务的返回值对象，而java.beans.Introspector会到处搜索BeanInfo信息，会返复的调用系统的ClassLoader对象，从而造成效率不高。（在并发请求很多时，会体现出来）
参看：https://issues.apache.org/jira/browse/AXIS2-4524
解决的直接办法是在服务端不使用Pojo的方式，而采用由axis1.5.5生成的Skeleton，这时效率会得到显著的提高。
但是，这样的方式在开发上比较麻烦。
目前，我采用的方法 ...