views:

341

answers:

4

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?

+2  A: 

Decorator pattern, I think. To create all flavors of Readers, Writers, input and output streams. See this, for example.

kohomologie
+5  A: 

The decorator pattern is often used in java i/o.

Example

BufferedReader br = new BufferedReader(new FileReader("filename.txt")); 
stacker
+12  A: 

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):

I'm pretty sure that one can find examples for almost all patterns listed on this wikipedia page in the Java SDK.

Andreas_D
+11  A: 

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 extend Vector. Similarly, a property list is not a hash table, so Properties should not extend Hashtable. In both cases, composition would have been preferable.

Related questions


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


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.

Related questions

polygenelubricants