Week 6, Class 1 & 2: Decorators Return Exam Questions about lab due tomorrow in class? Threads...
11
Week 6, Class 1 & 2: Decorators Return Exam Questions about lab due tomorrow in class? Threads Locking on null object invokeLater & the squares example Decorator & Java IO continued Decorator vs. List of Add-ons SE-2811 Slide design: Dr. Mark L. Hornick Content: Dr. Hornick Errors: Dr. Yoder 1
-
Upload
ira-stokes -
Category
Documents
-
view
213 -
download
0
Transcript of Week 6, Class 1 & 2: Decorators Return Exam Questions about lab due tomorrow in class? Threads...
Week 6, Class 1 & 2:Decorators
Return Exam Questions about lab due tomorrow in class?
Threads Locking on null object invokeLater & the squares example
Decorator & Java IO continued Decorator vs. List of Add-ons
SE-2811Slide design: Dr. Mark L. Hornick
Content: Dr. HornickErrors: Dr. Yoder
1
Decorator Pattern context
You want to attach additional functionality to an (existing) class dynamically…
…without having to resort to sub-classing the existing class We don’t want a class explosion
We want to allow classes to be easily “extended” to incorporate new behavior without modifying existing code.
2
SE-2811Dr. Mark L. Hornick 3
class GenericDecorator
«interface»Component
+ doStuff()() : void
ConcreteComponentA
+ doStuff()() : void
ConcreteComponentB
+ doStuff()() : void
«abstract decorator»Decorator
# wrappedComponent: Component
+ doStuff()() : void
ConcreteDecoratorX
+ doStuff()() : void
ConcreteDecoratorY
+ doStuff()() : void
*
wrappedComponent
1
+ doMoreStuff()
+ doMoreStuff()
How are decorators useful? Decorators have the same super-type as the objects they decorate.
Helps organize: e.g., can put all beverage objects in the same data-structure Used when initializing super-class
One or more decorators can be used to wrap an object. Why is this useful? Can still get to specific & useful method
When creating the object By casting back to cream (leaves open question: Is it cream?) Test using instanceof
Can get more & more specific about the object with multiple decos. Don’t need all the classes for all combinations
The java.io package contains dozens of classes
OutputStream, FileOutputStream, PipedOutputStream, DataOutputStream, ObjectOutputStream, PrintStream, PrintWriter, …
Understanding the associations between them just by reading the Javadoc API is difficult
SE-2811Dr. Mark L. Hornick 5
Knowing that the input stream classes are based on the Decorator pattern can make things easier
SE-2811Dr. Mark L. Hornick 6
class Input Stream Decorators
io::InputStream
- SKIP_BUFFER_SIZE: int = 2048 {readOnly}- skipBuffer: byte ([])
+ read() : int+ read(byte[]) : int+ read(byte[], int, int) : int+ skip(long) : long+ available() : int+ close() : void+ mark(int) : void+ reset() : void+ markSupported() : boolean
io::FilterInputStream
# in: volatile InputStream
# FilterInputStream(InputStream)+ read() : int+ read(byte[]) : int+ read(byte[], int, int) : int+ skip(long) : long+ available() : int+ close() : void+ mark(int) : void+ reset() : void+ markSupported() : boolean
io::FileInputStream
io::StringBufferInputStream
io::PipedInputStream io::LineNumberInputStream
io::BufferedInputStream
#in
<<deprecated>>
The Decorator pattern applied to output streams
SE-2811Dr. Mark L. Hornick 7
class Output Stream Decorators
io::OutputStream
+ write(int) : void+ write(byte[]) : void+ write(byte[], int, int) : void+ flush() : void+ close() : void
io::FilterOutputStream
# out: OutputStream
+ FilterOutputStream(OutputStream)+ write(int) : void+ write(byte[]) : void+ write(byte[], int, int) : void+ flush() : void+ close() : void
io::FileOutputStream
Appendable
io::PrintStream
io::PipedOutputStream
Writer
io::PrintWriter
io::ObjectOutputStream io::DataOutputStream
#out
-psOut
Only for error propagation in my Java version
Decorator vs. Array of Add-ons
SE-2811Dr. Mark L. Hornick 8
Design Principles
T? Reduce coupling Abstract classes are unliked
T Increase cohesion T Encapsulate what varies
E.g. mocha class only cares about chocolate Favor composition over inheritance T Program to interfaces, not implementations T Classes should be open for extension
but closed for modification
Which of these are met?SE-2811
Dr. Mark L. Hornick 9
Downsides
What are the disadvantages of decorators? Need to pay attention to abstract classes & type
SE-2811Dr. Mark L. Hornick 10
SE-2811Dr. Mark L. Hornick 11
class GenericDecorator
«interface»Component
+ doStuff()() : void
ConcreteComponentA
+ doStuff()() : void
ConcreteComponentB
+ doStuff()() : void
«abstract decorator»Decorator
# wrappedComponent: Component
+ doStuff()() : void
ConcreteDecoratorX
+ doStuff()() : void
ConcreteDecoratorY
+ doStuff()() : void
*
wrappedComponent
1
