BlogJava-Raul的思想碎片-文章分类-网络文摘

用十年学习编程 / Teach Yourself Programming in Ten Years (摘自Bigleo的blog)

风之子的小家 — Tue, 16 Aug 2005 06:04:00 GMT

前几天，系里排课，有教师讲“语言课（C++、JAVA等）随便找个老师就能上”。我哑然，如果计算机专业的老师都这样，我不知，会教出什么样的学生来。

今天浏览互联网，无意看到下面的文章，大家看后可以点评。以下是译文与原文。

用十年学习编程

为什么每个人都急不可耐？

走进任何一家书店，你会看见《Teach Yourself Java in 7 Days》（7天Java无师自通）的旁边是一长排看不到尽头的类似书籍，它们要教会你Visual Basic、Windows、Internet等等，而只需要几天甚至几小时。我在Amazon.com上进行了如下搜索：
　　　　pubdate: after 1992 and title: days and (title: learn or title: teach yourself)
　　　　(出版日期：1992年后 and 书名：天 and （书名：学会 or 书名：无师自通）)
我一共得到了248个搜索结果。前面的78个是计算机书籍（第79个是《Learn Bengali in 30 days》，30天学会孟加拉语）。我把关键词“days”换成“hours”，得到了非常相似的结果：这次有253本书，头77本是计算机书籍，第78本是《Teach Yourself Grammar and Style in 24 Hours》（24小时学会文法和文体）。头200本书中，有96%是计算机书籍。
结论是，要么是人们非常急于学会计算机，要么就是不知道为什么计算机惊人地简单，比任何东西都容易学会。没有一本书是要在几天里教会人们欣赏贝多芬或者量子物理学，甚至怎样给狗打扮。
让我们来分析一下像《Learn Pascal in Three Days》（3天学会Pascal）这样的题目到底是什么意思：

学会：在3天时间里，你不够时间写一些有意义的程序，并从它们的失败与成功中学习。你不够时间跟一些有经验的程序员一起工作，你不会知道在那样的环境中是什么滋味。简而言之，没有足够的时间让你学到很多东西。所以这些书谈论的只是表面上的精通，而非深入的理解。如Alexander Pope（英国诗人、作家，1688-1744）所言，一知半解是危险的（a little learning is a dangerous thing）

Pascal：在3天时间里你可以学会Pascal的语法（如果你已经会一门类似的语言），但你无法学到多少如何运用这些语法。简而言之，如果你是，比如说一个Basic程序员，你可以学会用Pascal语法写出Basic风格的程序，但你学不到Pascal真正的优点（和缺点）。那关键在哪里？Alan Perlis（ACM第一任主席，图灵奖得主，1922-1990）曾经说过：“如果一门语言不能影响你对编程的想法，那它就不值得去学”。另一种观点是，有时候你不得不学一点Pascal（更可能是Visual Basic和javascript之类）的皮毛，因为你需要接触现有的工具，用来完成特定的任务。但此时你不是在学习如何编程，你是在学习如何完成任务。

3天：不幸的是，这是不够的，正如下一节所言。

10年编程无师自通

一些研究者（Hayes、Bloom）的研究表明，在许多领域，都需要大约10 年时间才能培养出专业技能，包括国际象棋、作曲、绘画、钢琴、游泳、网球，以及神经心理学和拓扑学的研究。似乎并不存在真正的捷径：即使是莫扎特，他4 岁就显露出音乐天才，在他写出世界级的音乐之前仍然用了超过13年时间。再看另一种音乐类型的披头士，他们似乎是在1964年的Ed Sullivan节目中突然冒头的。但其实他们从1957年就开始表演了，即使他们很早就显示出了巨大的吸引力，他们第一次真正的成功——Sgt. Peppers——也要到1967年才发行。Samuel Johnson（英国诗人）认为10 年还是不够的：“任何领域的卓越成就都只能通过一生的努力来获得；稍低一点的代价也换不来。”（Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price.）乔叟（Chaucer，英国诗人，1340-1400）也抱怨说：“生命如此短暂，掌握技艺却要如此长久。”（the lyf so short, the craft so long to lerne.）
下面是我在编程这个行当里获得成功的处方：

对编程感兴趣，因为乐趣而去编程。确定始终都能保持足够的乐趣，以致你能够将10年时间投入其中。

跟其他程序员交谈；阅读其他程序。这比任何书籍或训练课程都更重要。

编程。最好的学习是从实践中学习。用更加技术性的语言来讲，“个体在特定领域最高水平的表现不是作为长期的经验的结果而自动获得的，但即使是非常富有经验的个体也可以通过刻意的努力而提高其表现水平。”（p. 366），而且“最有效的学习要求为特定个体制定适当难度的任务，有意义的反馈，以及重复及改正错误的机会。”（p. 20-21）《Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life》（在实践中认知：心智、数学和日常生活的文化）是关于这个观点的一本有趣的参考书。

如果你愿意，在大学里花上4年时间（或者再花几年读研究生）。这能让你获得一些工作的入门资格，还能让你对此领域有更深入的理解，但如果你不喜欢进学校，（作出一点牺牲）你在工作中也同样能获得类似的经验。在任何情况下，单从书本上学习都是不够的。“计算机科学的教育不会让任何人成为内行的程序员，正如研究画笔和颜料不会让任何人成为内行的画家”, Eric Raymond，《The New Hacker's Dictionary》（新黑客字典）的作者如是说。我曾经雇用过的最优秀的程序员之一仅有高中学历；但他创造出了许多伟大的软件，甚至有讨论他本人的新闻组，而且股票期权让他达到我无法企及的富有程度（译注：指Jamie Zawinski，Xemacs和Netscape的作者）。

跟别的程序员一起完成项目。在一些项目中成为最好的程序员；在其他一些项目中当最差的一个。当你是最好的程序员时，你要测试自己领导项目的能力，并通过你的洞见鼓舞其他人。当你是最差的时候，你学习高手们在做些什么，以及他们不喜欢做什么（因为他们让你帮他们做那些事）。

接手别的程序员完成项目。用心理解别人编写的程序。看看在没有最初的程序员在场的时候理解和修改程序需要些什么。想一想怎样设计你的程序才能让别人接手维护你的程序时更容易一些。

学会至少半打编程语言。包括一门支持类抽象（class abstraction）的语言（如Java或C++），一门支持函数抽象（functional abstraction）的语言（如Lisp或ML），一门支持句法抽象（syntactic abstraction）的语言（如Lisp），一门支持说明性规约（declarative specification）的语言（如Prolog或C++模版），一门支持协程（coroutine）的语言（如Icon或Scheme），以及一门支持并行处理（parallelism）的语言（如Sisal）。

记住在“计算机科学”这个词组里包含“计算机”这个词。了解你的计算机执行一条指令要多长时间，从内存中取一个word要多长时间（包括缓存命中和未命中的情况），从磁盘上读取连续的数据要多长时间，定位到磁盘上的新位置又要多长时间。（答案在这里。）

尝试参与到一项语言标准化工作中。可以是ANSI C++委员会，也可以是决定自己团队的编码风格到底采用2个空格的缩进还是4个。不论是哪一种，你都可以学到在这门语言中到底人们喜欢些什么，他们有多喜欢，甚至有可能稍微了解为什么他们会有这样的感觉。

拥有尽快从语言标准化工作中抽身的良好判断力。

抱着这些想法，我很怀疑从书上到底能学到多少东西。在我第一个孩子出生前，我读完了所有“怎样……”的书，却仍然感到自己是个茫无头绪的新手。30个月后，我第二个孩子出生的时候，我重新拿起那些书来复习了吗？不。相反，我依靠我自己的经验，结果比专家写的几千页东西更有用更靠得住。
Fred Brooks在他的短文《No Silver Bullets》（没有银弹）中确立了如何发现杰出的软件设计者的三步规划：

尽早系统地识别出最好的设计者群体。

指派一个事业上的导师负责有潜质的对象的发展，小心地帮他保持职业生涯的履历。

让成长中的设计师们有机会互相影响，互相激励。

这实际上是假定了有些人本身就具有成为杰出设计师的必要潜质；要做的只是引导他们前进。Alan Perlis说得更简洁：“每个人都可以被教授如何雕塑；而对米开朗基罗来说，能教给他的倒是怎样能够不去雕塑。杰出的程序员也一样”。
所以尽管去买那些Java书；你很可能会从中找到些用处。但你的生活，或者你作为程序员的真正的专业技术，并不会因此在24小时、24天甚至24个月内发生真正的变化。

Teach Yourself Programming in Ten Years

Why is everyone in such a rush?
Walk into any bookstore, and you'll see how to Teach Yourself Java in 7 Days alongside endless variations offering to teach Visual Basic, Windows, the Internet, and so on in a few days or hours. I did the following power search at Amazon.com:
pubdate: after 1992 and title: days and
(title: learn or title: teach yourself)
and got back 248 hits. The first 78 were computer books (number 79 was Learn Bengali in 30 days). I replaced "days" with "hours" and got remarkably similar results: 253 more books, with 77 computer books followed by Teach Yourself Grammar and Style in 24 Hours at number 78. Out of the top 200 total, 96% were computer books.
The conclusion is that either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days.

Let's analyze what a title like Learn Pascal in Three Days could mean:

Learn: In 3 days you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in that environment. In short, you won't have time to learn much. So they can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.

Pascal: In 3 days you might be able to learn the syntax of Pascal (if you already knew a similar language), but you couldn't learn much about how to use the syntax. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using Pascal syntax, but you couldn't learn what Pascal is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of Pascal (or more likely, something like Visual Basic or javascript) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.

in Three Days: Unfortunately, this is not enough, as the next section shows.
Teach Yourself Programming in Ten Years
Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene, appearing on the Ed Sullivan show in 1964. But they had been playing since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967. Samuel Johnson thought it took longer than ten years: "Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price." And Chaucer complained "the lyf so short, the craft so long to lerne."
Here's my recipe for programming success:

Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.

Talk to other programmers; read other programs. This is more important than any book or training course.

Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.

If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and through stock options is no doubt much richer than I'll ever be.

Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).

Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.

Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

Remember that there is a "computer" in "computer science". Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk. (Answers here.)

Get involved in a language standardization effort. It could be the ANSI C++ committee, or it could be deciding if your local coding style will have 2 or 4 space indentation levels. Either way, you learn about what other people like in a language, how deeply they feel so, and perhaps even a little about why they feel so.

Have the good sense to get off the language standardization effort as quickly as possible.
With all that in mind, its questionable how far you can get just by book learning. Before my first child was born, I read all the How To books, and still felt like a clueless novice. 30 Months later, when my second child was due, did I go back to the books for a refresher? No. Instead, I relied on my personal experience, which turned out to be far more useful and reassuring to me than the thousands of pages written by experts.
Fred Brooks, in his essay No Silver Bullets identified a three-part plan for finding great software designers:

Systematically identify top designers as early as possible.

Assign a career mentor to be responsible for the development of the prospect and carefully keep a career file.

Provide opportunities for growing designers to interact and stimulate each other.

This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers".
So go ahead and buy that Java book; you'll probably get some use out of it. But you won't change your life, or your real overall expertise as a programmer in 24 hours, days, or even months.

References
Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.
http://www.norvig.com/

风之子的小家 2005-08-16 14:04 发表评论

求职面试自我介绍一分钟选择自 fy198392 的 Blog

风之子的小家 — Wed, 10 Aug 2005 14:36:00 GMT

一段短短的自我介绍，其实是为了揭开更深入的面谈而设的。

　　一分钟的自我介绍，犹如商品广告，在短短60秒内，针对“客户”的需要，将自己最美好的一面，毫无保留地表现出来，不但要令对方留下深刻的印象，还要即时引发起“购买欲”。

　　自我认识想一矢中的，首先必须知道你能带给公司什么好处。当然不能空口讲白话，必须有事实加以证明。

　　最理想就是能够“展示”过去的成就。例如你曾为以往的公司设计网页，并得过奖项或赞扬。当然，这些例子都必须与现在公司的业务性质有关。

　　职位愈高，自我认识就愈重要，应将个人的成败得失，尽录在日记中。这样，就可以时刻都清楚自己的弱点与强项。

　　投其所好清楚自己的强项后，便可以开始预备自我介绍的内容：包括工作模式、优点、技能，突出成就、专业知识、学术背景等。

　　好处众多，但只有短短一分钟，所以一切还是与该公司有关的好。如果是一间电脑软件公司，应说些电脑软件的话题；如是一间金融财务公司，便可跟他说钱的事，总之投其所好。

　　但有一点必须紧记：话题所到之处，必须突出自己对该公司做出的贡献，如增加营业额、减低成本、发掘新市场等。

　　铺排次序内容的次序亦极重要，是否能紧握听众的注意力，全在于事件的编排方式。所以排在头位的，应是你最想他记得的事情。而这些事情，一般都是你最得意之作。与此同时，可呈上一些有关的作品或记录增加印象分。

　　身体语言不管内容如何精彩绝伦，若没有美丽的包装，还是不成的。所以在自我介绍当中，必须留意自己在各方面的表现，尤其是声线。切忌以背诵朗读的口吻介绍自己。最好事前找些朋友作练习对象，尽量令声线听来流畅自然，充满自信。

　　身体语言也是重要的一环，尤其是眼神接触。这不但令听众专心，也可表现自信。

　　曾有一项报告指出，日常的沟通，非语言性的占了70%.所以，若想面试成功，便应紧记注意一下你的身体语言。

　　面试问题及回答技巧大公开

　　http://www.cer.net2004-01-13；10：06

　　1、我们为什么要聘用你

　　（测试你的沉静与自信。）给一个简短、有礼貌的回答：“我能做好我要做的事情、”我相信自己，我想得到这份工作。

　　2、为什么你想到这里来工作

　　（这应该是你喜爱的题目。）因为你在此前进行了大量的准备，你了解这家公司。组织几个原因，最好是简短而切合实际的。

　　3、这个职位最吸引你的是什么

　　（这是一个表现你对这个公司、这份工作看法的机会。）回答应使考官确认你具备他要求的素质。

　　4、你是否喜欢你老板的职位

　　回答当然是“YES，如你不满意，可补充：”当我有这个评测能力时，或“有这样一个空缺时吧。

　　5、你是否愿意去公司派你去的那个地方

　　如果你回答“NO，你可能会因此而失掉这份工作，记住：你被雇用后你可以和公司就这个问题再行谈判。

　　6、谁曾经给你最大的影响

　　选一个名字即可，最好是你过去的老师等，再简短准备几句说明为什么。

　　7、你将在这家公司呆多久

　　回答这样的问题，你该持有一种明确的态度，即：能待多久待多久，尽可能长，“我在这里继续学习和完善自己。

　　8、什么是你最大的成就

　　准备一两个成功的小故事。

　　9、你能提供一些参考证明吗

　　你该准备好一些相关的整洁的打印件，并有现在的电话和地址。

　　10、从现在开始算，未来的五年，你想自己成为什么样子？或者：告诉我，你事业的目标

　　回答一定要得体，根据你的能力和经历。

　　11、你有和这份工作相关的训练或品质吗

　　说明要短，举两三个最重要的品质，要有事实依据。

　　12、导致你成功的因素是什么

　　回答要短，让考官自己去探究，比如只一句话：“我喜欢挑战性工作。

　　13、你最低的薪金要求是多少

　　（这是必不可少的问题，因为你和你的考官出于不同考虑都十分关心它。）你聪明的做法是：不做正面回答。强调你最感兴趣的是这个机遇和挑战并存的工作，避免讨论经济上的报酬，直到你被雇用为止。

　　14、你还有什么问题吗

　　你必须回答“当然。你要准备通过你的发问，了解更多关于这家公司、这次面试、这份工作的信息。

　　假如你笑笑说“没有（心里想着终于结束了，长长吐了口气），那才是犯了一个大错误。这往往被理解为你对该公司、对这份工作没有太深厚的兴趣；其次，从最实际的考虑出发，你难道不想听话听音敲打一下考官，推断一下自己入围有几成希望？

　　这里有一些供你选择的问题：1、为什么这个职位要公开招聘？2、这家公司（这个部门）最大的挑战是什么？3、公司的长远目标和战略计划您能否用一两句话简要为我介绍一下？4、您考虑这个职位上供职的人应有什么素质？5、决定雇用的时间大致期限要多久？6、关于我的资格与能力问题，您还有什么要问的吗？

　　求职面试必考题大公开

　　http://www.cer.net2004-013；10：16

　　以下归纳常见的面试必考题，前往面试前别忘了事先仿真自己的答案或请亲朋好友赶快给你建议哟！

　　为什么选择来本公司应征？

　　这是所有应征者必先遇到的问题，以积极、正面的答案回答，除说明公司的待遇、福利等条件吸引人之外，可进一步说明此工作可活用自己的专长。

　　为什么辞去前一份工作？

　　此时如果一味批评以前的工作，便很难被录用。而应说明是为了“实现自我”之类了话语。此外，无工作经验者则可对应征公司的性质，表现出兴趣作答。

　　过去的工作经历如何？

　　社会新鲜人可尽量提出所有打工或兼职的经验，甚至曾义务帮助过学校，其它团体或亲朋好友的工作经验皆可补充，最好能具体说明

风之子的小家 2005-08-10 22:36 发表评论

设计迷踪:给JAVA设计开发新手的一些建议和意见(二) 选择自 scud 的 Blog

风之子的小家 — Wed, 27 Jul 2005 14:34:00 GMT

【处理好你的异常】
-----------------

异常处理是Java编程中非常重要的一个部分.建议在使用异常之前阅读或者.

下面从书中摘出几条建议:
  *绝对不要忽略异常
  *千万不要隐藏异常***
  *仅在不正常的情况下使用异常
  *对可恢复的情况使用可检查异常,对程序错误使用运行时异常(RunTimeException)
  *给方法引发的异常做文档
  *在详细信息里面包括失败捕获信息
  *使用finally避免资源泄漏
  *....

在这里特别提出的是,在开发中要特别处理NULL的情况,否则经常引发NullPointException异常,在Java里这是一个最令人头疼的异常了.
如果你的程序因为一个NULL值,而报了几十个NullPointException的话,不但得让人烦死,而且还非常难以找到错误所在.所以在Java中一定要注意这个问题.
如果你的函数不允许Null值,那么可以截获它,抛出一个异常,或者给客户更友好的提示,难道不好吗?

让我们来看一个例子:

  public String getName(User aUser)
{
  //如果aUser为Null,会发生什么情况
  return aUser.getName();
}

很明显,如果参数为Null,就会抛出异常.应该改为:

public String getName(User aUser)
{
  if(null=aUser)
  {
   return "";
  }
  else
  {
   return aUser.getName();
  }
}

或者你要求参数不能为空,还可以抛出一个异常,强制使用者不能传入空值.

还有经常被忽略的是RunTimeException和普通异常的区别,在Java中,这是一个特殊的异常类,程序中如果遇到这个异常,用户可以不截获它,而如果是其他的普通异常,就不许要截获它.我们的代码经常这么写:

try
{
//your code here
}
catch(Exception e)
{
//do warn
}

这样写的话,就截获了所有异常,当然也包括了RunTimeException. 在很多情况下,这是不合适的处理方式,我们只应截获必要的异常,而应该忽略RuntimeException.

关于RunTimeException,在Spring中还有更好的利用方式,建议阅读Spring框架中在事务中对异常的处理代码,例如对Jdbc抛出的SqlException的转换.

关于异常处理,我提出几点建议:
  *捕获异常而且再次抛出时要包含原来的异常信息
  *不要忘了RunTimeException,除非必要,否则不要用catch(Exception e)的方式捕获所有异常.
  *不要用异常做流程控制,异常的性能代价比较高昂.(对此,可能有人不同意.此处不详细讨论)
  *不要把异常处理都抛给别人,本函数有能力处理的就不要抛出.

在此建议读者详细阅读或者.

【过度依赖】

在定位错误的时候,经常遇到浏览了七八个文件还是没有找到什么地方执行了真正需要的函数,这个时候就非常郁闷.A调用了B,B调用了C,C调用了D......让人找不到北

面对这样的程序,存在的问题不仅仅是定位错误麻烦,而且如果需要维护这样的函数库/框架,恐怕你的有非常高的统御能力才行,否则打死我也不去维护.

那么我们自己最好不要写这样的程序出来给人用.

【滥用接口】

现在流行"面对接口编程",这本身本来是不错,但是滥用接口的现象却经常发生.
"面向接口",于是所有的类都有一个对应的接口,接口的函数声明和类一模一样,而且一个接口只有一个类来实现它.这样的面向接口有什么意义哪? (为了用Spring的事务的情况除外)

根据"迪比特法则(Law of Demter)",一个对象应当对其他对象有尽可能少的了解.一个接口内应该只定义对方所需要的方法,而不要把一些没用的方法声明放在接口里面.

例如如下一个类:

  public class MyCounter
  {
   private int n1;
   private int n2;
   public MyCounter(int n1,int n2)
   {
    this.n1=n1;
    this.n2=n2;
   }

   public void setN1(int n1)
   {
    return this.n1 = n1;
   }
   public void setN2(int n2)
   {
    return this.n2 = n2;
   }
   public int getN1()
   {
    return n1;
   }
   public int getN2()
   {
    return n2;
   }

   public int getResult()
   {
    return n1 + n2;
   }
  }

我们可以看到,这个类的主要目的是得到计算结果,所以正确的接口应该类似:

  public interface Counter
  {
   int getResult();
  }

但是很多情况下,经常是这样的接口:

  public interface Counter
  {
   int getResult();
   int getN1();
   int getN2();
   void setN1(int n1);
   void setN2(int n2);
  }

我们想一想,这样做有2个后果:
  1.除了getResult之外,其他的函数我们根本用不到,所以是多余的.
  2.如果我们要自己实现一个Counter,如果接口中仅仅定义了getResult,我们仅仅需要实现它就可以了.我们自己的类可能是多个数运算,有乘除加减等等各种运算,参数也有可能是一些数组.但是如果按照第二种方法声明接口的话,我们就必须实现后面的四个方法,如果这样的话,实现这样东西不仅没用,而且浪费时间.我们恐怕要大声骂娘了吧.

所以,接口有好的作用,但是不要滥用.
■ 如果你的接口永远只有一个类实现,那么可能就没有必要用接口.
■ 你的接口只需要声明别人用到的函数即可.

风之子的小家 2005-07-27 22:34 发表评论

设计迷踪:给JAVA设计开发新手的一些建议和意见(一) 选择自 scud 的 Blog

风之子的小家 — Wed, 27 Jul 2005 14:31:00 GMT

为了给朋友同事一些设计问题上的指导,特撰写此文,很多观点都是从别人的文章中获取,有些观点肯定也有偏颇,有些观点也仅仅是提出并没有做详细论述,请多拍砖,以便改正.

【概述】
-------
在工作中,作为一个程序员或者一个设计师,总是要设计一些函数库或者一个框架,当然最经常的还是做项目,即使是一个项目,也会被经常改动,甚至交给别人改动.
当你做这些工作的时候,你的这些成果都是要给别人了解使用的,或者说给以后的你使用的,为了别人的方便或者为了自己的方便,我们要尽可能做好设计.

【放正心态,任何东西都是不断发展的】
----------------------------------

技术是日新月异的,每一天都有新的技术出来,正所谓"山外有山,人外有人",每一个新的轮子出来,都可能比你要设计的轮子好,所以在设计的时候,应该了解一下是否已经有了类似的轮子,是否要设计一个新的轮子.
即使你的轮子已经设计好了,也不好认为自己的轮子一定比别人的轮子好,虽然你的轮子可能更适合你的实际使用.
技术在不断的发展中,你以及你的朋友/同事都在不断进步,"士别三日,当刮目相看",所以不要认为你的水平一定比别人高,"尺有所短,寸有所长",所以别人对你的函数库/框架提出意见,提出疑问的时候,请不要惊奇,不要反感,不要认为别人在"挑刺",也许你的函数库/框架早就不适合当前的发展了.

态度决定一切.你的领导或许更重视这一点.

【必要的组成部分:单元测试,文档,实例,手册etc】
--------------------------------------------

单元测试,文档,API Doc,手册,演示程序,Change Log,Readme,build.xml等等

有一天别人使用了你设计的函数库/框架,当你升级后,原来的项目却不能工作了,经过一天的调试,你终于找到了原因,原来是不小心写错了一个东西.
你肯定不希望上述的事情发生,那么请你写单元测试吧,这样既不浪费自己的时间,也不耽误别人的工作,何乐而不为.你花在写单元测试的时间/带来的乐趣和你升级后改正莫名其妙的错误的时间和苦恼相比,肯定更有价值.你看到单元测试的绿条,难道不感到高兴吗?!
如果你不能保证你的程序修改没有错误,不要指望你的同事认为你的错误是可以容忍的,他们在心里早就开始骂你了,呵呵.写单元测试吧

看看任何一个知名的框架,都包含完善的文档,单元测试,示例程序,用户手册,那么请你也包含这些吧.哦,对了,请详细地写好JavaDoc,它很重要.

使用你的框架/函数库的人如果到处去找使用方法,去找某个类(但是他不知道是否有这个类),那么说明你的文档没有到位.如果你希望别人使用你的这个类或者功能,那么请写好文档,不要指望别人去读你的源码然后就能理解它是干什么用的.

如果你做到这些,那么你的函数库/框架也有了"知名"的前提,难道不是吗?如果没有,我想是没法让别人更好地使用的.

对了,有了这些东西,还要有一个良好的目录组织,这个也可以参考别的框架的组织方式.

【借鉴成熟的设计,参考已有的项目】
--------------------------------

1.要做一个新的东西,没有想法.不要惊讶,我肯定先找一个现有的东西来借鉴.

当然前提是不要重新发明轮子,或者是你有充分条件要重新发明一个轮子.
Struts,WebWork,Spring等等都是成熟的框架,不管你使用起来是否符合你的习惯.
在你成为大师之前,你的设计思想估计前人都已经提出并实践过了,所以要勇敢地去借鉴."站在巨人的肩膀上"我们能更近一步.

例如我们厌倦了在访问数据库时使用如下的代码:

  try
  {
   //your code here
  }
  catch(Exception e)
  {
   //catch Exception
  }
  finally
  {
   //must do something
  }

我们就可以借鉴Spring框架的JdbcTemplate类,看看它是如何利用回调函数来处理的.

我们使用hibernate时是不是也会使用类似上面的代码,那么可以参考Spring框架的HibernateTemplate.

借鉴也是一种捷径.

警告:借鉴但不要抄袭,借鉴代码要注明来源,尊重他人也是尊重自己.

2.在实际的项目中,往往可以参考已经有的项目来做自己的设计.

例如做一个网站,我不知道如何访问数据库,如何布局,如何分层,那么我们可以参考已经有的网站程序,看看别人是如何利用SiteMesh或者tiles布局,如何使用Hibernate来访问数据库或者使用已经封装好的JDBC类来访问数据库,如何利用Struts,WebWork或者其他访问来分层.


【遵守约定俗成的一些做法】
-------------------------

为了使别人更方便地使用你的东西,那么在设计一些通用的函数或者类的时候,请遵守通用的做法,不要与众不同,除非你的内部实现确实与众不同.

例如实现一个类似ArrayList的类,那么请不要这样写:

public int count()
{
return list.size();
}
public Item getItem(int i)
{
return list.get(i);
}

而应该这样:

public int size()
{
return list.size();
}
public Item get(int i)
{
return list.get(i);
}

当然每个人都有自己的想法,如果你非常认为你原来的方式比普通的好,那么请提供2套方式供别人选择.它不会给你带来麻烦,只是一个一看就懂的做法,不用怀疑,这样做有好处.

很多类的设计都有一些约定俗成的做法,那么在你设计一个新类的时候,先借鉴一下吧,多看看JDK的源码/文档,看看别人是怎么实现的.这更有助于推广你的成果.

【不要迷信权威】
---------------

在使用已有的框架或者函数库时,不要认为所有的东西都是正确的或者是最好的最好,肯定不是.没有完美的东西,已经存在的东西在设计的时候因为种种局限或者因为作者的水平,对现在来说肯定存在不合理的设计,或者过于理想化的设计,而不能满足实际情况.

不迷信权威,才能到达新的境界.

【不要轻易排斥,不了解就不要草率发表意见,要严谨】
------------------------------------------------

在网上经常看到.Net和Java的比较/火拼,或者是Struts VS Webwork或者是其他等等,非常之多.经常看到的是一方对对方的东西不甚了解,就开始批评,结果说不到点子上,反而被嘲笑一番.
几种技术的比较有时候是必要的,例如技术选型的时候.但是如果一些对这些技术根本不了解的人来选型,来评判,你能对结果信服吗?
存在就是合理,任何技术都有其存在的理由,虽然有些东西早就过时了,但是在当时它也是应运而生的.
几种技术,都是来解决同样的问题,但是问题也有很多方面,解决方式也有很多种,每个人的想法也都不一样,思路也不一样,所以没有绝对符合要求的技术,但是应该有符合你的技术,不符合你的技术不等于也不满足别人的要求.所以不要轻易排斥别的东西.

在做技术比较的时候,如果你不了解,那么请不要轻易发表意见,至少你可以亲自去了解,去实践之后在发表你的意见岂不是更好.

在发表意见的时候,也要严谨,不要轻易下结论,要经过求证,否则一旦错误只会让对手笑话,让你的同事看不起你.例如你说Hibernate3不支持jdk1.3,那么最好去好好找到你的证据,否则就会成为错误.(Hibernate3支持jdk1.3)

作为一个技术人员,严谨应该是我们的习惯之一,无论做开发还是做设计.

风之子的小家 2005-07-27 22:31 发表评论