Rich Cohen

Seems like the iterator method plays the role of a factory method, it produces an object that implements the Iterator interface. The iterator method is an abstract method on Collection, so each class that implements Collection can provide its own implementation of Iterator.

Originally posted by Alistair:
Actually, it's the "hire good people" like that most often gets the "that's cheating!" line.
Hire a small handfull of good people, and you don't have to worry about process at all - they'll take care of the issues all by themselves.

Forming a team of good people and leaving them to solve the problem seems like the extree essence of agile, lightweight methodologies. The likely success of this scenario stems in part from the likelihood that these good, experienced team members understand (explicitly or implicitly) the critical, important aspects of team coordination and software development, having addressed practical solutions to these issues in the past, and can be expected to work together as a new team to establish common solutions among themselves -- without requiring an externally-imposed heavy-weight methodology. You could say you don't need to dictate a light-weight methodology to the team, because they will quickly evolve one themselves. Part of the advantage of having an explicitly defined process is that new or less-experienced team members and contribute and learn along the way.

XP is a collection of practices and principles. One of the principles is not to expend effort on a complete design before beginning construction of the system. If you consider only this one aspect of XP, then you might well describe XP as a "licence to hack."
But XP advocates much more than this one principle. Other XP practices work in conjunction with rapid, iterative, incremental implementations of a system to circumscribe the "licence to hack". (XP is a collection of principles and practices; it is not a methodology and does not dictate specifically how things should be done. So there can be variation in how different groups adopt XP. So anything below that sounds like a dictum of XP should be read as an example of an XP principle.)
One XP practice outlaws working beyond a normal work day/week. (Ok, so just hack during working hours.) Additionally, all coding is done in pairs. This does not preclude hacking, but does mean another member of the development team is working with you as you evolve your design and develop your code -- following your line of thought and your design decisions, asking questions and suggesting alternatives as the work progresses. Further, XP says that you always build unit tests for your classes. These are not practices I associate with "just hacking," but maybe you know more disciplined hackers than I do.
XP also says that you should "refactor mercilessly." One aspect of that is that when you need to extend a class, and the class implementation does not readily admit your extension, rather than "just add something that will work for now," you refactor the class so that your extension fits easily and naturally.
Because XP teams practice "collective code ownership," everyone can see everyone elses code. So if someone violates the team coding standard, that is obvious. If someone builds a bad abstraction, everyone is free to see it, discuss it, and refactor it. (Although the code is "owned collectively," that does not mean that the team doesn't discuss changes and use a source code management system. It just means that no code is hidden, and no one person is a procedural bottle-neck to fixing code that needs fixing or enhancing. One of the fundamental principles of XP is communication. So, of course, the team is expected to let each other know about significant changes and refactorings they make along the way.)
Earlier notes in this thread suggested that the practice of a continually evolving design might be considered to emphasize design, rather than deemphasize it. Good point! A key point about refactoring is that you are not randomly reimplementing a class. You are making incremental improvements to enhance the clarity and structure of your classes. Hacking says you never go back to fix something with more than chewing gum and duct tape. XP says that you refactor and clean it up when you need to fix it. One of the benefits of pair programming is that, while you might do the chewing-gum it if working alone late at night, working with a co-worker in broad daylight may encourage you to respect the agreed-upon team practices.
So, is XP a "license to hack"? Well, if by hacking you mean pair programming, building unit tests, continuously improving the design of your individual classes and your program, always trying to keep your code as simple as possible, and refactoring (at least a little) when you encounter existing code that is no longer clean and simple, then you can say XP is a "licence to hack".

Originally posted by marc bowden:
Hi
What does 'refactor' mean - is it synonymous with
rewrite - ie the process or rewriting (re-design/
programming) programs, modules, sub-systems or
other chunks of code?
Marc

Refactoring is is one way of rewriting a program. It has a few
key characteristics. First, it preserves the program functionality. Second, it is done incrementally in small steps.
Other messages in this thread have quoted examples, so I won't.
Each step leaves the program fully functional. So you can stop
your refactoring work at (almost) any point and the program remains fully usable. This is in contrast with a traditional rewrite, in which the program may be unusable for long periods of time.
Refactoring is often associated with enhancing programs. This is because adding a new capability to a program may require some internal restructuring. You can refactor the program before adding your enhancement, so that making the enhancement is easier.
Practical use of refactoring is also associated with unit testing (and often with the JUnit testing framework), because after each refactoring step you want to verify that the program still works. The easiest way to do that is to run your regression tests. If you have a good set of regression tests for your program, then after each refactoring step you rerun the tests. If the tests pass, then you know your refactoring did not break the code. If the tests fail, then you know that the problem resides with the small code change you just made. You can either back it out or figure out why it was wrong. Since each refactoring step is small, this is pretty easy and the traditional "search for the bug" is largely eliminated.
This implicitly addresses one of the problems with a massive rewrite of code -- the resulting new mass of code requires massive testing and debugging. By performing the testing as you make the incremental code changes, you avoid the massive debugging step. Further, after a massive rewrite, the new code cannot be released until it has been entirely tested. So if you have to stop short of the complete effort, no part of the new code may be available for release. The incremental nature of refactoring avoids this all-or-nothing problem.
Another nice side effect of incremental refactoring is that you can improve an existing code base when you only have a few hours or a day to spend on it. For example, in the 3 or 4 days you spend building an enhancement, you might spend 1/2 day refactoring the existing code along the way.

I do not recommend Cooper's book on design patterns in Java. It does have good UML diagrams. In the few sections I read, his examples seemed to obscure the use of the design pattern more than they illustrated it.

The method BufferedReader.readLine is specified to return null at end-of-file. So just call readLine until it returns null.