`
lpn520
  • 浏览: 47114 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

“过度设计”之真实例子

阅读更多
  我刚到了一家新公司,公司给我的感觉很不错,不过当开始做第一个项目时便有过度设计的嫌疑,项目不大,基本就实现CURD的功能,用struts2+spring+ibatis+extjs。拿我开发的一个简单的功能来讲,就花了大概一周,如果采用简化的技术,实际上可能只需要一两天。

  设计太多的分层,以及偶和性太高,添加或修改一个模块太困难了,而且还不知道会不会影响到其它模块。按照项目定义的规范做法,写一个Hello world,创建的代码文件个数必须达到8个!!!!

  过度分层已经成为过度设计的一个典型。项目经理说,这是另一个项目的架构直接搬过来用的,我们做一下架构上的优化。

  其实本来就没有什么优化,原来本就是简单的东西,为了显示技术,搞得特复杂。现在所谓的优化,实际上回归质朴而已。

  记得OSI7层模型就有过度设计嫌疑,可以去看一下现在的教材,都没有用OSI作为例子,尤其没有专门讨论会话层。

  如何防止过度设计,最好办法就是使用敏捷编程,他的思路就是刚刚好就行,如果有问题,再重构。另外我自己目前的实践方法就是多编程,少设计,好像也能避免。因为当你的任务主要是写代码的时候,你绝不会去写8个类来完成一个helloworld。

  其实,我所说的就是开发原型,也是《敏捷开发方法》里提到过的方法。


分享到:
评论
270 楼 piao_bo_yi 2011-01-07  
lpn520 写道
downpour 写道
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。

我可以简单回答你的几个困惑。

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。


看了你的评论,我真的,很怀疑你没有认真看我的帖子,或根本没有理解我的本意。
对于开发分层,我只能说现在的分层太形式化了,我只是想革新现在这种过于形式的编程而已。
至于说帖子应该出现在05年以前,我很遗憾的告诉你,05年我还在读书, 至于现在来讨论有何不可呢?技术本来就是一种更新换代的东西,不是一成不变的。
至于希望我更多的思考, 其实我也想叫你思考:据国外的某机构统计,现在的JAVA的B/S开发生产率远不如PHP,可以说JAVA占尽的优势,可会出现这样的结果,这是为什么呢? 你不觉得这个才是悲哀吗?像你这种这么不给晚辈空间的人,以后你儿子可能也会成为你的悲哀。。。

看了你帮我回答的几个困惑,我非常感谢,1、3 这两点我的总结已经写的很清楚了。
关于Service层和Action层被证明是必须独立分开的2个层次,虽然我很赞同你的观点,我以前的几个项目也是这么做的,但也没有达到必须分开的地步,还是要跟项目的实际需求、项目大小及项目开发资源而定。
Action是表示MVC中的Controller,我觉得你真的应该去看看书了,可能你很牛B,不需要看书,但是我还是劝你翻开《Struts2 in Action》的37页第7行看看。  Action它本身没有任何控制的行为,何来控制可言, 即使你实现了一层抽象的Action加了一些控制进去,那它也只是Model+Controller的一个合体而已。

关于过度设计,我的帖子上也只是说有过度设计之嫌,我也只是在呼吁“编程应该尽可能简单”的敏捷开发思想而已。。




downpour 的回答一看就是很有经验的人。struts2在整个SSH架构中的确是Controller,负责消息转发。
269 楼 gtssgtss 2011-01-07  
IcedCoffee 写道
lpn520 写道
jasph77 写道
构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置,你还是一个普通的程序员。
架构师也是个人,他的架构必然也有不完美地方。

最讨厌那种,整天说这个不好、那个行,自己又没解决方案。


给你看看我之前做的解决方案,同样“添加删除修改查询”,同样是Struts2+Spring+iBATIS+ExtJs

前端
helloWorld.jsp       //用过Ext的都知道,页面是不需要写HTML代码的,所以helloWorld.js直接可以省掉,直接把js写在jsp文件里,还有用EXT直接使用原生态的,封装一层只的很恶心

业务层
HelloWorldAction.java     //struts2的Action,本身就是动作的意思,为什么它不叫Controllor呢,因为控制类已经在它内部封装好了,你实现了Action接口,只要在类里写业务就可以了,再加上struts2每个请求可以对应到Action的一个个方法上,所以万恶的HelloWorldServer.java和HelloWorldServerImp.java可以去掉了

DAO层
再讨论一下DAO层,我们用了ibatis框架,他本身就是个DAO层的实现,你每个SQL调起来就像调用DAO里的每个方法一样,所以HelloWordDao.java就可以去掉了,像HelloWordDao.java里的每个方法就一条代码,有意思吗
所以只要下面两个文件就可以了
HelloWord.java          //HelloWord表的ORM的对象
HelloWord.xml           //HelloWord表操作的SQL语句,ibatis的sqlmap


无语了..那干脆dao也去掉,放进action算了...


很多时候就是可以这样,建议看看oschina掌门人写的“Spring 事务管理高级应用难点剖析”
268 楼 chenjunxt 2011-01-07  
楼主的经验应该不多吧,分层的作用还没弄明白,碰到的问题还比较少,碰到的问题多了,自然就懂了
267 楼 mdsp25xhm 2010-10-29  
优点:细分层,明确各个层次对应的处理类,方便维护。
缺点:开发效率底,项目文件繁冗。
266 楼 suciudeman 2010-10-11  
兰州小菜,helloworld.jsp也不该写,完全可以用template.jsp代替,heolloworld.js,helloworldaction.java 通通可以用模板替代的,真正意义上只用个url传些参数就可以了。
265 楼 okjesse 2010-10-03  
分层的多少应该取决于业务,当你能确定业务和业务的可变范围时,应该把层次尽可能减少,因为在增加层次的同时也会增加代码的可读性和复杂性。如果你确定了业务可变范围了,如你所说,只是简单增删改,对框架的质疑我觉得楼主你是一百个对的。
但有些项目会有二期三期维护,可能会有很多变化,这时候多些层次会对后期修改带来很多便利。这个时候其实可以把这些层次看作是预留接口的作用。
264 楼 BruceXX 2010-10-02  
兄弟,你思想还是太浅了。
263 楼 mercyblitz 2010-10-02  
downpour 写道
不想再引起额外的口水战,对于这种早有结论的讨论,没有任何意义。我会向管理员申请锁定,不要让错误的讨论继续误导大家的思维。


首先,很多人没有把帖子全部看完,很早的下结论。讨论的目的不是要引起什么口水战,而是开放思维大家讨论,在一定程度上对人都与好处,当然不免会影响部分初学者。以理服人,大家都是公平的。

开发没有什么定式,如果说JSP页面不能写Java代码是Java的习惯的,那么RoR或者ASP是不是没有存在的必要呢?

模式是双刃剑,看场景分情况,如此而已。


262 楼 xhdwell 2010-10-02  
lpn520 写道
hjb1029 写道
说到底,楼主还没理解mvc真正的含义,丢恒生的脸啊。

可能我需要向您学习,但请你说话还是别太绝对, 我曾经自己写了一个轻量级的MVC框架, 丢不丢恒生的脸, 不是你说得算。。。

我觉得这个问题拿出来讨论很好啊。一开始看这贴也觉得楼主好菜,但随着讨论深入发现问题远远没想象中的简单,很多我们认为理所当然的概念如果你深入讨论下去就会出现很多疑问,这才是创新的前提。
261 楼 fsword 2010-10-01  
这个话题已经讨论的很长了,我另外开了一帖把话题集中在分层的原因上,欢迎参与
260 楼 downpour 2010-10-01  
不想再引起额外的口水战,对于这种早有结论的讨论,没有任何意义。我会向管理员申请锁定,不要让错误的讨论继续误导大家的思维。
259 楼 mercyblitz 2010-10-01  
downpour 写道
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。



兄弟,你说的悲哀。只能说明你参加工作早,先看到这些东西,你要知道有很多新人进入这个行业。为什么不能讨论?

再说,你首先没有看前面的讨论内容。

downpour 写道

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。 Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。


1.泛型DAO?只能说在ORM的帮助下,可以抽象出一个DAO用于简单的,楼主不是初学者。复杂的查询没有什么用。

2.职责单一是没有错,但是要分情况考虑,不一定需要提出业务逻辑到Service,给一个理由为什么不能把事务放到Action里面。再说Struts这个东西,Action可以为Model或者Controllor,要看Service是否需要公用。比如,只有一个查询工作,难道还要提出一个Service出来?

3.这个是很简单的问题,HTML作结构,CSS管样式,JS控制行为。分离他们是为了不至于为了其一,而重新编译页面,一般生产环境是不开放及时翻译和编译JSP的。





258 楼 lpn520 2010-10-01  
downpour 写道
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。

我可以简单回答你的几个困惑。

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。


看了你的评论,我真的,很怀疑你没有认真看我的帖子,或根本没有理解我的本意。
对于开发分层,我只能说现在的分层太形式化了,我只是想革新现在这种过于形式的编程而已。
至于说帖子应该出现在05年以前,我很遗憾的告诉你,05年我还在读书, 至于现在来讨论有何不可呢?技术本来就是一种更新换代的东西,不是一成不变的。
至于希望我更多的思考, 其实我也想叫你思考:据国外的某机构统计,现在的JAVA的B/S开发生产率远不如PHP,可以说JAVA占尽的优势,可会出现这样的结果,这是为什么呢? 你不觉得这个才是悲哀吗?像你这种这么不给晚辈空间的人,以后你儿子可能也会成为你的悲哀。。。

看了你帮我回答的几个困惑,我非常感谢,1、3 这两点我的总结已经写的很清楚了。
关于Service层和Action层被证明是必须独立分开的2个层次,虽然我很赞同你的观点,我以前的几个项目也是这么做的,但也没有达到必须分开的地步,还是要跟项目的实际需求、项目大小及项目开发资源而定。
Action是表示MVC中的Controller,我觉得你真的应该去看看书了,可能你很牛B,不需要看书,但是我还是劝你翻开《Struts2 in Action》的37页第7行看看。  Action它本身没有任何控制的行为,何来控制可言, 即使你实现了一层抽象的Action加了一些控制进去,那它也只是Model+Controller的一个合体而已。

关于过度设计,我的帖子上也只是说有过度设计之嫌,我也只是在呼吁“编程应该尽可能简单”的敏捷开发思想而已。。

257 楼 downpour 2010-10-01  
lpn520 写道

通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。
我大概的总结一下:

前端:
helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。

DAO层:
其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。

Service层:
目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。





这种分层开发讨论的帖子,应该出现在05年以前,现在再来讨论,并且讨论了25页,实在是让人觉得是一种悲哀。我把帖子投到新手区,希望楼主更多的思考。

我可以简单回答你的几个困惑。

1. DAO层被证明是可以简化的,至少会一个非常薄的层次。在绝大多数的情况下,DAO层是可以省略的,或者使用一个GenericDao的通用设计即可。Javaeye上已经出现过很多通用DAO的尝试,并且非常成功,楼主可以去查找一下。但是当项目成倍扩张后,DAO作为一个独立的层次就显得比较有必要,因为独立的DAO能够从类和接口声明2个不同的角度诠释一个调用的逻辑含义。

2. Service层和Action层被证明是必须独立分开的2个层次。将2个层次分开的原因很多,其中一个重要原因是Service层将被用于事务的隔离,而Action层是不适合作为事务配置的层次。Action是表示层MVC中的Controller,而Service是业务逻辑层的接口表述,所以这两者的职责是完全不同的。把逻辑全部放到

3. 从你们使用EXTJS的情况看,这个与JSP同名的文件的本意可能是用于渲染页面的。这个是否是过度设计要视项目的情况而言。
256 楼 cn-done 2010-10-01  
原来大家都纠结在框架分层设计上了。其实本人的观念是框架不能单纯的从技术角度出发,需要结合业务,具体的场景才能设计出复合当前项目开发的框架。楼主提出的问题,也是现在开发分层的通病,有点教条主义了。没有全能的框架,简单易用、高效才是硬道理。
255 楼 grave 2010-10-01  
我想那个hello world人家也是那你了解一下框架而已,跟过度设计有什么关系吗,这个hello world只是为了展现一些编程上的契约,跟具体实现的功能无关。
254 楼 peterwei 2010-10-01  
abiandbel 写道
看到有个同学说的不错。

是到了我们做java的去好好看看ROR的时候。
跳出来去看看,对我们做Java的也有好处。

ROR为什么没有接口?
ROR有所谓的分层么?

ROR在敏捷开发方面比Java好在哪里?或者坏在哪里?
ROR在领域驱动设计开发为什么能比Java做的好?

这些问题我们应该试着去寻找一下答案了。

恩。。。的确是到跳出Java,去看看其他语言或者架构的时候了。

哈哈,这个说的。跳出Java,到RoR,人家在Java优势,为什么用ROR?就像Java的人让C的搞Java一样。很多东西,说白了就那么回事。人在江湖,身不由已。
253 楼 peterwei 2010-10-01  
<div class="quote_title">lpn520 写道</div>
<div class="quote_div">
<p>通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。<br>我大概的总结一下:<br><br>前端:<br>helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。<br><br>DAO层:<br>其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。<br><br>Service层:<br>目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。</p>
<p> </p>
<p> 当然是需求及成本,业务复杂度等各层面决定是否需要Service层。没有一招吃遍天下的,具体情况具体分析。</p>
</div>
<p> </p>
252 楼 abiandbel 2010-09-30  
看到有个同学说的不错。

是到了我们做java的去好好看看ROR的时候。
跳出来去看看,对我们做Java的也有好处。

ROR为什么没有接口?
ROR有所谓的分层么?

ROR在敏捷开发方面比Java好在哪里?或者坏在哪里?
ROR在领域驱动设计开发为什么能比Java做的好?

这些问题我们应该试着去寻找一下答案了。

恩。。。的确是到跳出Java,去看看其他语言或者架构的时候了。
251 楼 lpn520 2010-09-30  
<p>通过几天的讨论,其实收获很大,不管是赞同我的也好,还是骂我的也好,我都非常感谢你们,在这里祝大家国庆快乐哦。<br>我大概的总结一下:<br><br>前端:<br>helloWorld.jsp和helloWorld.js分不分开其实是小问题,爱咋嘀咋嘀。关于对EXT的封装,网友们还是觉得不封装比较好,没有什么争议。<br><br>DAO层:<br>其实ibatis就已经帮我们实现DAO层了,用了ibatis本身在代码里就不用写SQL了,再加上也有泛化的DAO,也没有什么争议。<br><br>Service层:<br>目前争议最大的是Service层,我的观点是struts2的Action可以代替Service,而广大网友的观点是Service必不可少,也有一部份的网友认为,可以用struts2的Action代替Service。 关于这个问题,其实我想问,Service真的是必不可少吗? 是否每个项目都必须要呢? 是因为需求的需要,还是因为它是规范呢? 这个问题有待讨论。 当然我也知道Service层的好处,我曾经的项目也有用到过,正因为我用过,我才敢把它砍掉。</p>
<p> </p>
<p> </p>

相关推荐

    MVP例子一看你就懂

    - **避免过度设计**:虽然MVP模式有诸多优点,但过度使用可能导致代码过于复杂。需要根据项目的具体需求来决定是否采用MVP。 - **合理组织Presenter**:大型项目中,一个Presenter可能会变得非常庞大,这时可以考虑...

    工业设计史设计改革PPT教案.pptx

    法国展出的油灯和女士工作台等例子,揭示了设计中装饰性过强,甚至超过了其实用性。 美国的参展作品则呈现出截然不同的风格,农机和军械等产品朴实无华,直接反映了工业化生产的特点和功能。这使得人们开始反思设计...

    当代设计研究理念—用户体验超人性化设计方法.docx

    上海地铁使用者的设计研究是一个很好的例子。研究者通过观察法、访谈法和自我陈述法收集素材,对乘客的真实行为、环境和时间进行分类,进而分析乘客的需求。他们将复杂的乘客行为过程简化为一系列环节,并通过马斯洛...

    给用户体验设计师的10条UX建议 .doc

    7. 留白的艺术:设计应避免过度复杂,注重留白,如滴滴出行的设计,简洁的设计能提升app的品质感和使用效率。 8. 不要把情感置于逻辑之上:视觉设计应服务于功能逻辑,美观的设计如果功能逻辑混乱,反而会干扰用户...

    阻尼效果的例子

    - **性能优化**:使用节流和防抖技术来提高代码执行效率,避免过度渲染导致的性能问题。 通过实践这些示例,你可以深入理解阻尼效果的实现原理,并将它们应用到自己的项目中,创造出更加逼真的交互体验。同时,这也...

    Unity3d下CurvedUI使用例子

    在Unity3D中,UI设计是构建用户界面的关键部分,而CurvedUI则为开发者提供了一种创建曲面或弯曲界面的独特工具,使得UI元素能够在各种非平面的显示环境中更加自然和沉浸。 "Unity3d下CurvedUI使用例子"这个项目可能...

    打篮球与设计模式(关于设计模式)

    - 如果过度使用组合模式,可能会导致系统设计过于复杂。 ##### 8. **装饰模式 (Decorator)** 装饰模式允许在运行时动态地给一个对象添加新的功能。文中提到了将篮球场改造成足球场和舞会场地的例子。这相当于装饰...

    C#设计模式.PDF

    这部分内容将通过具体的例子来介绍设计模式的应用场景,帮助读者理解不同设计模式如何解决特定的问题。 ### 3. 先有鸡还是先有蛋? 这是一个引人思考的问题,旨在探讨软件设计中的某些基本哲学问题,比如在软件...

    autocomplete自动补全官方网站的例子

    7. 案例研究:为了进一步理解实际应用,官方网站可能会提供真实的使用场景或案例,帮助开发者了解如何在项目中集成自动补全功能。 总之,通过学习官方网站提供的自动补全例子,开发者可以掌握这一功能的核心原理和...

    极限编程的例子 老师发的课件

    2. 朴素(Simplicity):提倡以最简单的方式来解决问题,避免过度设计。 3. 反馈(Feedback):通过持续集成和测试,确保团队及时了解项目的进展和问题。 4. 勇气(Courage):鼓励团队面对困难,勇于改正错误和改进...

    《正确认识广告》第2课时示范课教学设计【部编人教版小学四年级道德与法治上册】.docx

    通过展示虚假广告的例子,教师强调了《中华人民共和国广告法》的相关规定,即广告必须真实,不得欺骗消费者。这个环节旨在让学生理解虚假广告的危害,并提高他们的法律意识。 第二个环节是小组讨论,让学生探讨识别...

    23种设计模式的比喻

    - **缺点**: 可能会出现过度设计的情况,即在不需要使用组合模式的地方使用它。 **9. 装饰器模式 (DECORATOR)** - **应用场景**: 如果你想送给女友一个特别的生日礼物,比如一张照片,并希望在背后写上一些温馨的...

    MySQL一个索引最多有多少个列?真实的测试例子

    在设计表结构时,应谨慎选择需要建立索引的列,确保它们对最常见的查询具有高选择性,并且不会过度增加存储开销。如果需要基于更多列进行快速查询,可以考虑以下策略: - 使用复合索引,即包含最有区分性的前几个列...

    JavaScript设计模式之代理模式简单实例教程

    **JavaScript设计模式之代理模式详解** 代理模式是一种在软件设计中常见的模式,它允许我们创建一个代表原始对象的代理对象,以控制对原始对象的访问。代理对象可以在调用实际对象的方法之前或之后添加额外的功能,...

    初中语文文摘社会还有什么是真的

    例如,刘谦的魔术就是一个很好的例子,他公开表演的魔术虽然看似真实,但观众都知道那是经过精心设计的幻觉。因此,看到的不一定就是真实的,听到的更可能带有偏差。 在这个问题上,文章暗示了公众需要培养批判性...

    无视用户体验?白鸦微博集中吐槽阿里系应用.docx

    白鸦赞扬了天猫应用的设计和运营,认为这是阿里巴巴系中表现较好的例子,或许是因为其外包背景带来的外部视角和专业设计力量。这也暗示了引入外部资源和多元观点可以提升产品的设计质量。 最后,白鸦特别提到一淘...

    世界文化遗产的保护和可持续利用教案.docx

    - “世界文化遗产的价值”部分,通过具体的例子如高句丽王城、布达拉宫等,阐述文化遗产在历史研究和文化交流中的角色,引导学生认识不同民族和地区的文化特色。 - “世界文化遗产的保护原则”部分,强调文化遗产...

    IxD敏捷式研究

    在这种背景下,“敏捷”成为了应对挑战的关键策略之一。360移动互联网产品的案例解析为我们提供了一个深入了解敏捷式研究与设计实践的机会。 **抢占新需求** 根据数据统计,中国网民数量已达到3.88亿,占总人口的...

    统编人教版六年级下册道德与法治 第2课 学会宽容(第2课时) 教案(教学设计).doc

    7. **自我反思与成长**:鼓励学生自我反思,学会在面对自身错误时宽容自己,接纳真实的自我,同时也应有自我约束,避免因宽容过度而失去尊严。 8. **课堂总结**:强调宽容的价值,指出刻薄与宽容的差异,以及宽容对...

Global site tag (gtag.js) - Google Analytics