z***s
发帖数: 3241 | 1 我也搞了几年JAVA了，由于一向懒惰，没有成为大牛，只是一普通程序猿，不爱玩社交
网站，不爱玩微博，唯独喜欢百度贴吧，潜水很久了，手痒来给新人分享下从新手成长
为老鸟的已见，也刷刷存在感，应该不比曝照差吧。
首先初识语法的阶段，必须要学会怎么操作对象，操作if和for，操作list set map，
然后是线程、IO和jdbc什么的，其余的，若是一时不理解，可以后边需要时再学。
这阶段完了，你可以写些能在控制台打印出来的小程序，锻炼下逻辑思维。也就是号称
JAVASE毕业了，其实不过是入门而已，如果要往WEB方向发展，这些倒是基本足够了。
接下来要学HTML JSP SERVLET 数据库 JAVASCRIPT TOMCAT，目标，写出第一个动态网
站，也许只是个登陆功能，只能展示下个人资料，但这是很重要的一步，你要弄清楚的
是，一个用户的点击产生的请求，是从哪里发起，哪里接收，哪里处理，哪里返回，你
得理解浏览器和服务器的关系和分工，cookie和session，request和response。这个是
个WEB开发的学习初级阶段，这都是些JAVA诞生以来最原始的最官方的WEB开发技... 阅读全帖 |
|
s****y
发帖数: 503 | 2 做Android不需要知道J2EE的技术，你说的都是Android SDK的东西
像UI的方法，比如onClick，其实和设计模式有关，例如observer pattern |
|
s****y
发帖数: 503 | 3 做Android不需要知道J2EE的技术，你说的都是Android SDK的东西
像UI的方法，比如onClick，其实和设计模式有关，例如observer pattern |
|
b****u
发帖数: 1130 | 4 工作了4年多，平时也留意设计方面的东西。也在项目中套用不少设计模式。
但设计水平还是很差。有什么办法提高？ |
|
|
c********e
发帖数: 383 | 6 ai...even today i was reading the chap of advanced design pattern he co-oped
with andreil |
|
g*****g
发帖数: 34805 | 7 语言本身不会太复杂，C++比较复杂一点。
OOP思想也就那么一些，设计模式也就是
那么几种。但要把API熟悉了，没有几年功夫不太可能。 |
|
g*****g
发帖数: 34805 | 8 别的咱不懂，java吗，类库，流行架构，设计模式。 |
|
|
D*******a
发帖数: 3688 | 10 often
just name a few is ok |
|
b******n
发帖数: 592 | 11 I recently read a book: head first design pattern..it is in Java, and found
it quite good.. enjoyed the whole book..it is still nice to know.. |
|
|
N***m
发帖数: 4460 | 13 唉，这个初级程序员是不是用得不多阿？
貌似是给项目经理搞的。 |
|
g*****g
发帖数: 34805 | 14 No, most patterns are good practice and common designs. It's
everywhere in Java frameworks and JDK itself. PM don't care
about them, they may not know how to code Java either. |
|
|
N***m
发帖数: 4460 | 16 弱问一下，具体工作中编程，如果项目经理不搭好架子，
底下人怎么开始干活阿？是不是还有小组长之类的负责
具体搭架子工作啊？ |
|
g*********s
发帖数: 1782 | 17 for small projects, tech lead enough.
for big projects, high level guy would take the task. |
|
g*********s
发帖数: 1782 | 18 I also heard recommendations on this book. But I'm a C++ coder. Is it still
OK to read?
found |
|
b******n
发帖数: 592 | 19 I am C++ guy as well. It doesn't matter. I don't think anyone only use one
programming language. If you only use C++, probably it is time to look at
other
languages ;)
still |
|
g*********s
发帖数: 1782 | 20 Hands already very full. No spare time/energy to learn new stuff, although I
really want to.
I just order the book from amazon. Hopefully I can make use of those
compilation waiting windows to read it. |
|
z***e
发帖数: 5393 | 21 。。。你C++的直接去看design patterns那本书啊，那是基于C++讲的。head first
design pattern是完全针对java.
虽然说原理差不多。
still |
|
g*********s
发帖数: 1782 | 22 I tried but felt that book is boring and hard to follow, although I know it'
s the Bible.
It is said this one is more interesting and easier to read. |
|
T*********g
发帖数: 496 | 23 大多数代码在重构的时候，都会发现其实很多模式可以用。 |
|
|
|
|
d********w
发帖数: 363 | 27 这就是java的反射机制，hadoop规定了mapreduce的框架,用户需要写自己的map，和
reduce类，（继承于MapReduceBase），在main函数中通过JobConf把用户类给注入进去
，在通过jobclient执行，也可以说是设计模式中的template模式 |
|
r********3
发帖数: 2998 | 28 Java这些动态语言，已经改变了传统软件设计模式。比如依赖注入等很多概念，传统C/
C++无法体会。
特别是到了SOA, Web Service这个层次上的软件设计，没有reflection的语言来做开发
简直就是一场灾难。 |
|
|
s**********o
发帖数: 197 | 30 这个比喻太好了。相比C/C++，java。net更注重协同作战的能力。由于应用领域不同，
相同水平的程序员在C/C++的领域内会可能感觉更自由些。另外我最近学Java，感觉
Java对初学OOP的人来说比C++强许多。学Java一开始就能接触好多程序设计模式上的知
识，让你感觉不是在专门学某种语言，而是学编程本身。相反C++开始学的时候要了解
好多和语言相关的细节，一个运算符重载就可能扯出一堆内存分配效率的问题;可是当
你去写好多行程序的时候，很少人会follow当初学的那些细节问题，比如你在C++里写
new的时候根本不会去想你将来程序运行的系统是怎么地址对齐。但网上C++的教程和面
试问题又很喜欢和这些东西联系起来。 |
|
y**b
发帖数: 10166 | 31 打算重写多年前的C++程序数值模拟程序(有几万行代码)，觉得当初的设计比较糟糕，
扩展起来很痛苦。
C++的基础知识还可以，几本本经典的书籍也翻来覆去地阅读和理解，可是设计方面
很欠缺，这方面有什么特别经典的书籍值得推荐，还是直接学习设计模式？
再一个就是重新设计的时候要考虑分布式内存和共享式内存两种并行模式的综合运用
以便在上千个节点上进行并行运算，这方面显然也是设计重于编码，有没有什么好书？
谢谢。 |
|
g*****g
发帖数: 34805 | 32
整个JDK就是这么实现的。代码里很多地方都有System.getProperty，我相信
JDK比大多数C++系统在设计模式层面上做得更好。从技术层面上，配置属于
immutable的数据，local和global访问并无本质区别。
不是，他的意思是说你可以后面再加新的数据而不需要对singlton改动。
immutable的东西怎么传都行。 |
|
J*****n
发帖数: 4859 | 33 我有A, B两个类
在main function中，我call
Aobj.do_sth();
Bobj.do_sth();
现在我有一个C和D两个class，需要在A中计算。
简单的方法就是，把C,D作为nested class放在A中
class A{
C c;
D d;
A.do_sth {c.do_sth; d.do_sth}
}
现在的问题是，c.do_sth和d.do_sth中有些东西，我希望被Bobj所用。问题是main
function似乎不是那么好改，也就是说，我似乎不能写成
Bobj.do_sth(Aobj)
有什么建议可以解决这个问题么？
谢谢。 |
|
N***m
发帖数: 4460 | 34 can you change B.do_sth?
can you pass A to B? |
|
|
g*****g
发帖数: 34805 | 36 Pass A to B, add getter in A for C and D. |
|
|
|
h*******n
发帖数: 82 | 39 你说再多JAVA FRAMEWORK也好，scale ability名词也好，什么30M用户同时收到消息也
好，你所做的就是个低级的工作，管理好你的用户连接池，发送PLAIN TEXT， 我也不
想和你辩论网游里面数据传送，容错机制之类的了。就是想让你这种做网站的自以为是
的人知道，你再吹捧JAVA多好，你的网站有多少用户，你堆一大堆垃圾设计模式也改变
不了你们做的是发发文字，做做加减乘除的低等事情的事实。还有scalability不是你
做屁网站专业的专有名词，别人用Multi-GPU scalability 破解密码，渲染图像，物理
模拟什么不比你发text强, 我一两块小显卡同时能handle的Tasks比你几十台服务器都
强。
latency
handle
users.
users |
|
h*******n
发帖数: 82 | 40 你说再多JAVA FRAMEWORK也好，scale ability名词也好，什么30M用户同时收到消息也
好，你所做的就是个低级的工作，管理好你的用户连接池，发送PLAIN TEXT， 我也不
想和你辩论网游里面数据传送，容错机制之类的了。就是想让你这种做网站的自以为是
的人知道，你再吹捧JAVA多好，你的网站有多少用户，你堆一大堆垃圾设计模式也改变
不了你们做的是发发文字，做做加减乘除的低等事情的事实。还有scalability不是你
做屁网站专业的专有名词，别人用Multi-GPU scalability 破解密码，渲染图像，物理
模拟什么不比你发text强, 我一两块小显卡同时能handle的Tasks比你几十台服务器都
强。
latency
handle
users.
users |
|
c*****m
发帖数: 1160 | 41
with
that
这两年经常看到一些class里面有这样的getter和setter，有什么好处？直接把这个变
量public出来不就可以了么？
相信是gof里面的一个设计模式，但是我看过几次都没有理解。 |
|
g*****g
发帖数: 34805 | 42 另外一个变量可以是个private变量。比如有个变量a，为了方便或者效率，你有个另一
变量永远是2*a.
没有setter怎么弄？
设计模式不是讲究概率，目的就是为了decoupling。内部API随便写写还没事反正可以
refactor。一旦第三方要调用，你这么弄，一旦需要改，第三方都得跟着改代码。很多
时候这是不能接受的。
SetThisVariable( |
|
g*****g
发帖数: 34805 | 43 OO design pattern可以用任何OO语言写。但用什么写的跟大多数C++程序员懂不懂是是
俩回事。本版的大多数C++程序员还沉迷于回字几种写法，看看大多数讨论的问题就知
道了。
讨论设计模式，系统架构的问题平均一个月能有一次？就这某些ID还看不起Java程序员
实在搞笑。 |
|
g*****g
发帖数: 34805 | 44 做人怎么做都行，最基本的就是要尊重事实。本版就是经常讨论C++语言细节，很少讨
论系统设计。
你觉得讨论设计模式很奇怪，我还觉得讨论语言细节很奇怪。
说。
还沉 |
|
g*****g
发帖数: 34805 | 45 Design pattern这种东西。不同语言实现有所不同，因为语言所限有的不能实现。但大
部分思想还是一样的。本来就是一个好的实践被抽象出来。随着系统越来越大，越来越
复杂，面对的问题越来越多，各种设计模式必然越来越多。 |
|
g*****g
发帖数: 34805 | 46 简单的情况自然拿什么写都行。复杂的系统，难点通常不在于开始实现这个系统本身，
而在于系统不断增加新的特性和debug的过程能够保持系统的稳定性。整个OO的核心就
在于封装。从单个类的封装，对外隐藏了数据和私有逻辑。到类库封装，使得一系列复
杂实现对外简化成几个类的使用。而OO设计模式则大量牵涉到low coupling。当OO都不
够用的时候，自然而然地扩展到了SOA, loose coupling。服务底下封装的数据库和服
务器集群，部署，scalability, availability，都不是客户端需要考虑的问题。从而
达到了一个大系统decomposition的目的。不同的团队可以部署维护自己的一系列服务
，可以以自己的开发周期来发布。一个大而不可维护的数据库被分成了一个个小的数据
库，从而减少数据库瓶颈的问题。一个几百人的大项目，可以变成一系列的小项目，从
而减少人员交流的瓶颈，保持agile的开发。
整个OO的进化，项目大型化，伴随着工具，项目管理的进化。远远把FP抛在后面，已经
不是FP能够处理的。一个24写得再简洁，都不能说明问题。 |
|
