p*****2
发帖数: 21240 | 1 都用struts
spring主要就是用di aop |
r*****s
发帖数: 985 | 2 不是，
spring mvc是现在时，
struts有点out了，
这两个也不是一回事。
spring mvc主要是在backend serving rest/ajax calls，
前端用javascript framework。
spring framework是用了di等方法，
以loosely coupled modules
to provide almost all app server functions.
不过做点简单项目Work就好，
struts也就够了。
【在 p*****2 的大作中提到】
: 都用struts
: spring主要就是用di aop
|
p*****2
发帖数: 21240 | 3
多谢大牛。那struts就没有必要学了。Spring＋Hibernate才是未来的方向？不过
Srping的这些理念确实是大型的应用才有意义。小型应用真是没有必要。
【在 r*****s 的大作中提到】
: 不是，
: spring mvc是现在时，
: struts有点out了，
: 这两个也不是一回事。
: spring mvc主要是在backend serving rest/ajax calls，
: 前端用javascript framework。
: spring framework是用了di等方法，
: 以loosely coupled modules
: to provide almost all app server functions.
: 不过做点简单项目Work就好，
|
z*******3
发帖数: 13709 | 4 decoupling是所有项目的要求
【在 p*****2 的大作中提到】
:
: 多谢大牛。那struts就没有必要学了。Spring＋Hibernate才是未来的方向？不过
: Srping的这些理念确实是大型的应用才有意义。小型应用真是没有必要。
|
p*****2
发帖数: 21240 | 5
你是说所有Java项目的要求？
【在 z*******3 的大作中提到】
: decoupling是所有项目的要求
|
T****U
发帖数: 3344 | 6 ood的要求吧
【在 p*****2 的大作中提到】
:
: 你是说所有Java项目的要求？
|
p*****2
发帖数: 21240 | 7
C++有没有DI这种东西？
【在 T****U 的大作中提到】
: ood的要求吧
|
p*****2
发帖数: 21240 | 8 关于DI
没做过大项目，对于小项目有多少可能性一个interface会有几个implementation需要
DI呢？ |
z*******3
发帖数: 13709 | 9 是所有软件工程甚至是所有工程项目的要求
你学软件工程这门课的时候老师没告诉过你要loosely coupling和high cohesion？
【在 p*****2 的大作中提到】
: 关于DI
: 没做过大项目，对于小项目有多少可能性一个interface会有几个implementation需要
: DI呢？
|
p*****2
发帖数: 21240 | 10
感觉你说的这个跟DI还不是一回事。
【在 z*******3 的大作中提到】
: 是所有软件工程甚至是所有工程项目的要求
: 你学软件工程这门课的时候老师没告诉过你要loosely coupling和high cohesion？
|
|
|
T****U
发帖数: 3344 | 11 其实就是模块化的一种具体实现方法
【在 p*****2 的大作中提到】
:
: 感觉你说的这个跟DI还不是一回事。
|
z*******3
发帖数: 13709 | 12 di是一个pattern
所有的pattern都跟最初的思想有关
这些东西才是真正的精髓
万变不离其宗
无论struts还是spring，其实本质上也都是这些pattern和思想
还不是一样的
【在 p*****2 的大作中提到】
:
: 感觉你说的这个跟DI还不是一回事。
|
g*****g
发帖数: 34805 | 13 DI provides a way to simplify your service dependencies initialization, it
doesn't matter how many implementations you have.
【在 p*****2 的大作中提到】
: 关于DI
: 没做过大项目，对于小项目有多少可能性一个interface会有几个implementation需要
: DI呢？
|
g*****g
发帖数: 34805 | 14 It can't be done without reflection or pre-compilation. The former is not
available for C++, the latter is not portable.
【在 p*****2 的大作中提到】
:
: 感觉你说的这个跟DI还不是一回事。
|
p*****2
发帖数: 21240 | 15
所以编程按照松耦合来做，跟有没有DI没什么关系。
【在 z*******3 的大作中提到】
: di是一个pattern
: 所有的pattern都跟最初的思想有关
: 这些东西才是真正的精髓
: 万变不离其宗
: 无论struts还是spring，其实本质上也都是这些pattern和思想
: 还不是一样的
|
p*****2
发帖数: 21240 | 16
如果我只有一个implementation，我当然可以hard code了，没必要去配置xml。
【在 g*****g 的大作中提到】
: DI provides a way to simplify your service dependencies initialization, it
: doesn't matter how many implementations you have.
|
T****U
发帖数: 3344 | 17 what about upgrade, modification, maintenance, collaboration?
【在 p*****2 的大作中提到】
:
: 如果我只有一个implementation，我当然可以hard code了，没必要去配置xml。
|
p*****2
发帖数: 21240 | 18
这没什么问题呀。DI才出来几年，以前的程序不都好好的吗？我昨天看了一下DI，就是
把dependency放在XML里了。如果有多个implementation可以理解，如果只有一个hard
code不就行了吗, 根本就不影响upgrade, maintenance， collaboration这些呀。
【在 T****U 的大作中提到】
: what about upgrade, modification, maintenance, collaboration?
|
z*******3
发帖数: 13709 | 19 di是实现loosly coupling的一种方式
有其它方式，但是这种方式对开发人员要求少
【在 p*****2 的大作中提到】
:
: 这没什么问题呀。DI才出来几年，以前的程序不都好好的吗？我昨天看了一下DI，就是
: 把dependency放在XML里了。如果有多个implementation可以理解，如果只有一个hard
: code不就行了吗, 根本就不影响upgrade, maintenance， collaboration这些呀。
|
p*****2
发帖数: 21240 | 20
感觉滥用了也麻烦，不一定效果有多好。看了一些Java code就那么一种模式，也不管
到底code的本质是什么，把简单问题搞的很复杂。
【在 z*******3 的大作中提到】
: di是实现loosly coupling的一种方式
: 有其它方式，但是这种方式对开发人员要求少
|
|
|
z*******3
发帖数: 13709 | 21 什么叫做code的本质？
【在 p*****2 的大作中提到】
:
: 感觉滥用了也麻烦，不一定效果有多好。看了一些Java code就那么一种模式，也不管
: 到底code的本质是什么，把简单问题搞的很复杂。
|
T****U
发帖数: 3344 | 22 二爷追求效率，但是spring是为了简化维护和解决通用性问题的，效率肯定是有所降低
的。
其实这是现在程序的趋势，重点从节省代码量，提高运行速度变成提高可读性，可维护
性。起码大项目是这样的了。速度和效率都可以尽量通过硬件来弥补，但是工程管理的
复杂度不行，所以只有牺牲效率来保证对项目的可控性。
【在 z*******3 的大作中提到】
: 什么叫做code的本质？
|
p*****2
发帖数: 21240 | 23
比如做一件东西，本来就是一个class就可以了。结果做个interface出来，还做个
factory，然后再写一个class来实现这个interface。我的意思是说如果这个interface
只是有一个实现，直接写一个class就好了，干嘛搞出这么一个堆东西。你不想hard
code class，可是你还是要hard code interface呀。更可笑的是还把一个class分成了
两个class，为了看上去有两个implementation，可是里边大堆的冗余代码。看得我极
其confused。感觉就是生硬的套模式。
我很欣赏thinking in java里边说的，不要 overuse interface. 不知道是我们这边
java 程序员的问题还是java code都这么写。
【在 z*******3 的大作中提到】
: 什么叫做code的本质？
|
z*******3
发帖数: 13709 | 24 那为什么用java呢？
public static void main(String[] args)
没觉得这里面有很多东西么？
不麻烦么？
int main()多好，多简单
interface
【在 p*****2 的大作中提到】
:
: 比如做一件东西，本来就是一个class就可以了。结果做个interface出来，还做个
: factory，然后再写一个class来实现这个interface。我的意思是说如果这个interface
: 只是有一个实现，直接写一个class就好了，干嘛搞出这么一个堆东西。你不想hard
: code class，可是你还是要hard code interface呀。更可笑的是还把一个class分成了
: 两个class，为了看上去有两个implementation，可是里边大堆的冗余代码。看得我极
: 其confused。感觉就是生硬的套模式。
: 我很欣赏thinking in java里边说的，不要 overuse interface. 不知道是我们这边
: java 程序员的问题还是java code都这么写。
|
p*****2
发帖数: 21240 | 25
我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
。
【在 T****U 的大作中提到】
: 二爷追求效率，但是spring是为了简化维护和解决通用性问题的，效率肯定是有所降低
: 的。
: 其实这是现在程序的趋势，重点从节省代码量，提高运行速度变成提高可读性，可维护
: 性。起码大项目是这样的了。速度和效率都可以尽量通过硬件来弥补，但是工程管理的
: 复杂度不行，所以只有牺牲效率来保证对项目的可控性。
|
T****U
发帖数: 3344 | 26 紧耦合有好处，不过权衡利弊，大项目还是必须用松耦合的。
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
z*******3
发帖数: 13709 | 27 勤快人啊
我这种懒人就喜欢写那么一点东东
然后让别人把剩下的搞定
【在 T****U 的大作中提到】
: 二爷追求效率，但是spring是为了简化维护和解决通用性问题的，效率肯定是有所降低
: 的。
: 其实这是现在程序的趋势，重点从节省代码量，提高运行速度变成提高可读性，可维护
: 性。起码大项目是这样的了。速度和效率都可以尽量通过硬件来弥补，但是工程管理的
: 复杂度不行，所以只有牺牲效率来保证对项目的可控性。
|
T****U
发帖数: 3344 | 28 这也不是硬套模式，你如果能创造出合适的大家容易理解能接受的模式，也可以。
我们这里谈的都是很多人总结过的design patterns, 它们各自应该用在哪些方面已经被
充分研究过了，我们碰到类似情况当然应该直接套用，何必自己reinvent the wheel?
随意灵活的设计往往会成为混乱的设计，毕竟一个聪明人比一千个聪明人还聪明的情况
是少数。
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
T****U
发帖数: 3344 | 29 大牛，你要是懒人，就没人勤快了。
您老那些长篇大论我顶多只来得及读了1/3.
【在 z*******3 的大作中提到】
: 勤快人啊
: 我这种懒人就喜欢写那么一点东东
: 然后让别人把剩下的搞定
|
z*******3
发帖数: 13709 | 30 敲字远比码代码容易
敲字无所谓对错，思路和意思对就行
码代码有一堆的限制，纠结对错要纠结半天
所以大多数时候我都是用ide来帮忙写
真正代码量其实不多，当然我用工具生成的不少
【在 T****U 的大作中提到】
: 大牛，你要是懒人，就没人勤快了。
: 您老那些长篇大论我顶多只来得及读了1/3.
|
|
|
g*****g
发帖数: 34805 | 31 对于internal API，code to interface不是必须的。可以在第二个实现的时候再提出
来。
但对于public API，最好这么做。这是为了第三方扩展的需要。
interface
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
g*****g
发帖数: 34805 | 32 套用模式是为了简化设计。企业应用往往项目很大，开发人员很多。代码的质量取决于
最短的一块板，而不是最长的那块。一个规范化的架构底下，个人能造成的错误影响有
限。
另一方面，你看到的模式虽然繁琐，但通常boilerplate代码是在架构层面上实现了的
。典型的如Spring的Singleton，一个@Component的annotation就实现了，不能再简单
了。
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
k********e
发帖数: 368 | 33 用annotation更简单。
其实如果一个项目小的太小，可以全部使用public static。都不需要new了。
这样简单的项目基本太少了
hard
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
z****e
发帖数: 54598 | 34 singleton都不用加
spring缺省就是singleton
【在 g*****g 的大作中提到】
: 套用模式是为了简化设计。企业应用往往项目很大，开发人员很多。代码的质量取决于
: 最短的一块板，而不是最长的那块。一个规范化的架构底下，个人能造成的错误影响有
: 限。
: 另一方面，你看到的模式虽然繁琐，但通常boilerplate代码是在架构层面上实现了的
: 。典型的如Spring的Singleton，一个@Component的annotation就实现了，不能再简单
: 了。
|
g*****g
发帖数: 34805 | 35 You still need to declare it as @Component or @Service, @Respository etc.
【在 z****e 的大作中提到】
: singleton都不用加
: spring缺省就是singleton
|
z***s
发帖数: 3241 | 36 http://coolshell.cn/articles/8745.html
如此理解面向对象编程
2012年12月13日陈皓发表评论阅读评论 20,225 人阅读
从Rob Pike 的 Google+上的一个推看到了一篇叫《Understanding Object Oriented
Programming》的文章，我先把这篇文章简述一下，然后再说说老牌黑客Rob Pike的评
论。
先看这篇教程是怎么来讲述OOP的。它先给了下面这个问题，这个问题需要输出一段关
于操作系统的文字：假设Unix很不错，Windows很差。
这个把下面这段代码描述成是Hacker Solution。（这帮人觉得下面这叫黑客？我估计
这帮人真是没看过C语言的代码）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class PrintOS
{
public static void main(final String[] args)
{
String osName = System.getProperty("os.name") ;
if (osName.equals("SunOS") || osName.equals("Linux"))
{
System.out.println("This is a UNIX box and therefore good.") ;
}
else if (osName.equals("Windows NT") || osName.equals("Windows 95"))
{
System.out.println("This is a Windows box and therefore bad.") ;
}
else
{
System.out.println("This is not a box.") ;
}
}
}
然后开始用面向对象的编程方式一步一步地进化这个代码。
先是以过程化的思路来重构之。
过程化的方案
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public class PrintOS
{
private static String unixBox()
{
return "This is a UNIX box and therefore good." ;
}
private static String windowsBox()
{
return "This is a Windows box and therefore bad." ;
}
private static String defaultBox()
{
return "This is not a box." ;
}
private static String getTheString(final String osName)
{
if (osName.equals("SunOS") || osName.equals("Linux"))
{
return unixBox() ;
}
else if (osName.equals("Windows NT") ||osName.equals("Windows 95"))
{
return windowsBox() ;
}
else
{
return defaultBox() ;
}
}
public static void main(final String[] args)
{
System.out.println(getTheString(System.getProperty("os.name"))) ;
}
}
然后是一个幼稚的面向对象的思路。
幼稚的面向对象编程
PrintOS.java
1
2
3
4
5
6
7
public class PrintOS
{
public static void main(final String[] args)
{
System.out.println(OSDiscriminator.getBoxSpecifier().getStatement())
;
}
}
OSDiscriminator.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class OSDiscriminator // Factory Pattern
{
private static BoxSpecifier theBoxSpecifier = null ;
public static BoxSpecifier getBoxSpecifier()
{
if (theBoxSpecifier == null)
{
String osName = System.getProperty("os.name") ;
if (osName.equals("SunOS") || osName.equals("Linux"))
{
theBoxSpecifier = new UNIXBox() ;
}
else if (osName.equals("Windows NT") || osName.equals("Windows
95"))
{
theBoxSpecifier = new WindowsBox() ;
}
else
{
theBoxSpecifier = new DefaultBox () ;
}
}
return theBoxSpecifier ;
}
}
BoxSpecifier.java
1
2
3
4
public interface BoxSpecifier
{
String getStatement() ;
}
DefaultBox.java
1
2
3
4
5
6
7
public class DefaultBox implements BoxSpecifier
{
public String getStatement()
{
return "This is not a box." ;
}
}
UNIXBox.java
1
2
3
4
5
6
7
public class UNIXBox implements BoxSpecifier
{
public String getStatement()
{
return "This is a UNIX box and therefore good." ;
}
}
WindowsBox.java
1
2
3
4
5
6
7
public class WindowsBox implements BoxSpecifier
{
public String getStatement()
{
return "This is a Windows box and therefore bad." ;
}
}
他们觉得上面这段代码没有消除if语句，他们说这叫代码的“logic bottleneck”（逻
辑瓶颈），因为如果你要增加一个操作系统的判断的话，你不但要加个类，还要改那段
if-else的语句。
所以，他们整出一个叫Sophisticated的面向对象的解决方案。
OO大师的方案
注意其中的Design Pattern
PrintOS.java
1
2
3
4
5
6
7
public class PrintOS
{
public static void main(final String[] args)
{
System.out.println(OSDiscriminator.getBoxSpecifier().getStatement())
;
}
}
OSDiscriminator.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class OSDiscriminator // Factory Pattern
{
private static java.util.HashMap storage = new java.util.HashMap() ;
public static BoxSpecifier getBoxSpecifier()
{
BoxSpecifier value = (BoxSpecifier)storage.get(System.getProperty("
os.name")) ;
if (value == null)
return DefaultBox.value ;
return value ;
}
public static void register(final String key, final BoxSpecifier value)
{
storage.put(key, value) ; // Should guard against null keys,
actually.
}
static
{
WindowsBox.register() ;
UNIXBox.register() ;
MacBox.register() ;
}
}
BoxSpecifier.java
1
2
3
4
public interface BoxSpecifier
{
String getStatement() ;
}
DefaultBox.java
1
2
3
4
5
6
7
8
9
public class DefaultBox implements BoxSpecifier // Singleton Pattern
{
public static final DefaultBox value = new DefaultBox () ;
private DefaultBox() { }
public String getStatement()
{
return "This is not a box." ;
}
}
UNIXBox.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class UNIXBox implements BoxSpecifier // Singleton Pattern
{
public static final UNIXBox value = new UNIXBox() ;
private UNIXBox() { }
public String getStatement()
{
return "This is a UNIX box and therefore good." ;
}
public static final void register()
{
OSDiscriminator.register("SunOS", value) ;
OSDiscriminator.register("Linux", value) ;
}
}
WindowsBox.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class WindowsBox implements BoxSpecifier // Singleton Pattern
{
public static final WindowsBox value = new WindowsBox() ;
private WindowsBox() { }
public String getStatement()
{
return "This is a Windows box and therefore bad." ;
}
public static final void register()
{
OSDiscriminator.register("Windows NT", value) ;
OSDiscriminator.register("Windows 95", value) ;
}
}
MacBox.java
1
2
3
4
5
6
7
8
9
10
11
12
13
public class MacBox implements BoxSpecifier // Singleton Pattern
{
public static final MacBox value = new MacBox() ;
private MacBox() { }
public String getStatement()
{
return "This is a Macintosh box and therefore far superior." ;
}
public static final void register()
{
OSDiscriminator.register("Mac OS", value) ;
}
}
作者还非常的意地说，他加了一个“Mac OS”的东西。老实说，当我看到最后这段OO大
师搞出来的代码，我快要吐了。我瞬间想到了两件事：一个是以前酷壳上的《面向对象
是个骗局》和 《各种流行的编程方式》中说的“设计模式驱动编程”，另一个我想到
了那些被敏捷洗过脑的程序员和咨询师，也是这种德行。
于是我去看了一下第一作者Joseph Bergin的主页，这个Ph.D是果然刚刚完成了一本关
于敏捷和模式的书。
Rob Pike的评论
（Rob Pike是当年在Bell lab里和Ken一起搞Unix的主儿，后来和Ken开发了UTF-8，现
在还和Ken一起搞Go语言。注：不要以为Ken和Dennis是基友，其实他们才是真正的老基
友！）
Rob Pike在他的Google+的这贴里评论到这篇文章——
他并不确认这篇文章是不是搞笑？但是他觉得这些个写这篇文章是很认真的。他说他要
评论这篇文章是因为他们是一名Hacker，至少这个词出现在这篇文章的术语中。
他说，这个程序根本就不需要什么Object，只需要一张小小的配置表格，里面配置了对
应的操作系统和你想输出的文本。这不就完了。这么简单的设计，非常容易地扩展，他
们那个所谓的Hack Solution完全就是笨拙的代码。后面那些所谓的代码进化相当疯狂
和愚蠢的，这个完全误导了对编程的认知。
然后，他还说，他觉得这些OO的狂热份子非常害怕数据，他们喜欢用多层的类的关系来
完成一个本来只需要检索三行数据表的工作。他说他曾经听说有人在他的工作种用各种
OO的东西来替换While循环。（我听说中国Thoughtworks那帮搞敏捷的人的确喜欢用
Object来替换所有的if-else语句，他们甚至还喜欢把函数的行数限制在10行以内）
他还给了一个链接http://prog21.dadgum.com/156.html，你可以读一读。最后他说，OOP的本质就是——对数据和与之关联的行为进行编程。便就算是这样也不完全对，因为：
Sometimes data is just data and functions are just functions.
我的理解
我觉得，这篇文章的例子举得太差了，差得感觉就像是OO的高级黑。面向对象编程注重
的是：1）数据和其行为的打包封装，2）程序的接口和实现的解耦。你那怕，举一个多
个开关和多个电器的例子，不然就像STL中，一个排序算法对多个不同容器的例子，都
比这个例子要好得多得多。老实说，Java SDK里太多这样的东西了。
我以前给一些公司讲一些设计模式的培训课，我一再提到，那23个经典的设计模式和OO
半毛钱关系没有，只不过人家用OO来实现罢了。设计模式就三个准则：1）中意于组合
而不是继承，2）依赖于接口而不是实现，3）高内聚，低耦合。你看，这完全就是Unix
的设计准则。
（全文完）
（转载本站文章请注明作者和出处 酷壳 – CoolShell.cn ，请勿用于任何商业用途）
interface
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
n*w
发帖数: 3393 | 37 比如unit test
简单的项目可以不用container. di pattern 还是有好处的
hard
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
g*****g
发帖数: 34805 | 38 Most frameworks used annotation to handle di these days.
Even if you don't use DI, it's not simpler
Compare
private OtherService otherService;
public MyService(OtherService otherSerivce) {
this.otherService = otherService;
}
to
@Autowired
private OtherService otherService;
I don't see how the former can be simpler.
hard
【在 p*****2 的大作中提到】
:
: 我主要不喜欢那种生硬的套模式的编程方法。我喜欢灵活性，就事论事的设计。我感觉
: 程序也并不都是松耦合。可能在internet这个世界是这样。但是很多系统都是紧耦合的
: 。
|
