I was asked this question recently during my job interview, and I couldn't answer it. So, what is the most used pattern in java.io and how is it used? What are other patterns used in common java libraries?
Decorator pattern, I think. To create all flavors of Readers, Writers, input and output streams. See this, for example.
The decorator pattern is often used in java i/o.
Example
BufferedReader br = new BufferedReader(new FileReader("filename.txt"));
I guess they wanted to hear about the Decorator pattern which can be found in the various Streams, Readers and Writers.
Other patterns (small selection):
- Observer pattern in the swing libraries
- Factory pattern in the javax.xml.parsers packages
- Iterator pattern, used in collections
I'm pretty sure that one can find examples for almost all patterns listed on this wikipedia page in the Java SDK.
BufferedReader
etc implements decorator pattern. Any Reader
, e.g. FileReader
or StringReader
, can be decorated with the buffering feature, which is really source-oblivious.
Other patterns
Anti-patterns
To add to what others have said, these are several anti-patterns in the Java libraries:
Antipattern: inheritance instead of composition
From Effective Java 2nd Edition, Item 16: Favor composition over inheritance:
There are a number of obvious violations of this principle in the Java platform libraries. For example, a stack is not a vector, so
Stack
should not extendVector
. Similarly, a property list is not a hash table, soProperties
should not extendHashtable
. In both cases, composition would have been preferable.
Related questions
- Prefer composition over inheritance?
- java inheritance versus composition (implementing a stack)
- Difference between Inheritance and Composition
- Inheritance or composition: Rely on “is-a” and “has-a”?
- Object Oriented Best Practices - Inheritance v Composition v Interfaces
- Should I use inheritance or composition?
- Inheritance vs. Aggregation
- Aggregation verses Composition
- Decorator Pattern Using Composition Instead of Inheritance
Antipattern: constant interfaces
From Effective Java 2nd Edition, Item 19: Use interfaces only to define types:
There are several constant interfaces in the Java platform libraries, such as
java.io.ObjectStreamConstants
. These interfaces should be regarded as anomalies and should not be emulated.
Related questions
- Should a class implement a constants-only interface?
- What is the best way to implement constants in Java ?
Antipattern: telescoping constructor and JavaBeans patterns
From Effective Java 2nd Edition, Item 2: Consider a builder when faced with many constructor parameters (excerpt online):
Traditionally, programmers have used the telescoping constructor pattern, in which you provide a constructor with only the required parameters, another with a single optional parameters, a third with two optional parameters, and so on [...] The telescoping constructor pattern works, but it is hard to write client code when there are many parameters, and harder still to write it.
A second alternative when you are faced with many constructor parameters is the JavaBeans pattern, in which you call a parameterless constructor to create the object, and then call setter methods to set each required parameter, and each optional parameter of interest. [...] Unfortunately the JavaBeans pattern has serious disadvantages of its own [...] a JavaBean may be in an inconsistent state partway through its construction [and it] precludes the possibility of making a class immutable.
Bloch recommends using a builder pattern instead.