 Other books I am reading:
|
"While MySQL is greater than ever, it's actually 'too much database' for some jobs. "
"XSLT has a reputation among some users for being difficult to learn (probably a fair comment) and sluggish in performance (less fair, certainly today). "
"The findstr utility allows searches similar to those carried out using Widows Search but also supports more specific searches that include regular expressions. "
"Eclipse itself is more or less Visual Age for Java rewritten in Java and updated. "
"If you don't undersatnd everything going on in each listing, don't worry! That's what the rest of the book is for. "
"Das Buch is als Lehrbuch konzipiert und auch zum Selbststudium geeignet. "
"This book is aimed at the user with a basic understanding of a Linux or Unix-like operating system and preferably have some hands-on experience with Red Hat Linux or other Unix-like operating systems. "
"For those of you that have had no prior experience, this book still provides a great insight and starting place for installing and using Fedora 2. "
"The difference with this book is that it doesn't just introduce you to the language, it takes you into all its hidden corners. "
|
|
| | Quotable from Head First Design Patterns:
"A Decorator converts one interface to another, an Adapter doesn't alter the interface, but adds responsibility, and a Facade makes an interface simpler. " - p. 254 |
Edward's Notes:
"Back in 2003 I read the first Head First book called Head First Java while lying in the hospital for three days after a foot operation. I ended up reading it cover to cover in 36 hours -- it was worth a whole semester course on object oriented programming with its useful cartoons explaining inheritance and subclasses and inheritance, etc. I remember an excellent conversation between a procedural programmer and a OOP programmer where you saw how the procedural programmer actually got things finished more quickly at the beginning of the project but then towards the end, he started to get further and further behind as you saw how object oriented programming concepts saved the OOP programmer time and effort. That book was really a masterpiece in conveying a difficult topic. SO, what more difficult topic is there in our IT world other than Design Patterns, and that is the topic of this book. Looking through it I can see it has the same format using seemingly goofy but actually very insightful cartoons, e.g. the woman saying "This is stupid; why do we need all these classes? Can't we just use instance variables and inheritance in the superclass to keep track of the condiments?" I find these cartoons often contain statements that I have been dying to ask, and then you have them explained for you on the page. And the Head First books are great for commuters because you can learn huge chunks from them even if you are not sitting at a computer. If you have ever approached Design Patterns and couldn't really grok them, definately, definately get this book. Now, by the time I finish this book I hope the authors come out with Head First UML." (December 2004)
Are you reading this book, too?
Notes on "Introduction":
Notes on "Chapter 1: Welcome to Design Patterns":
| | 
| Starts with an easy duck example -- adds a method fly() which all ducks will inherit. Then something goes wrong (not all subclasses of duck can fly) and they fix it, considers inheritance, interfaces. The design principle is then: "Program to an interface, not an implementation". Learn to "program to a supertype", setting behavior dynamically, favor composition over inheritance. AFTER understanding and solving the problem, you are then told WHICH design pattern you used, i.e. Strategy Pattern. Nice introduction. Nice conversation between a "skeptical developer" and a guru. I like how they use simplified UML diagrams.
|
Notes on "Chapter 2: The Observer Pattern: Keeping your Objects in the Know":
| |
| You build an "Internet-based weather monitoring station" in this chapter. First you take a "misguided swag" at the problem, you discuss why it fails, then they show you how to do it right. Comparison to newspaper and magazine subscriptions. "The power of loose coupling". I really like their conversations, e.g. the cubicle conversation: the characters ask nice, pointed questions. Fireside chat between Subject and Observer. Java's built-in observer pattern. A character notices that the java.util.Observable has a design flaw (programs to implementations instead of interfaces). Discusses other places you'll find the Observer pattern: e.g. JavaBeans and Swing.
| | |  | "We're going to be talking about the Observer Pattern. That pattern is the best! It's the BEST, Jerry! " - p. 37 | | | | "Publishers + Subscribers = Observer Pattern " - p. 45 |
Notes on "Chapter 3: The Decorator Pattern: Decorating Objects":
| |
| In an example of software for a coffee shop, you see a class "Beverage" and then dozens of subclasses which inherit from it -- obviously a problem ("Whoa! Can you say 'class explosion'?"). Design Principle: Classes should be open for extension, but closed for modification. They discuss how to simplify all these classes, then they get down to using the decorator pattern ("Decorate it with a Mocha object"). Cubicle conversation about Inheritance vs. Composition. Real world decorators: Java I/O. "Confessions of a Decorator" interview
| | | | "Once you know the techniques of decorating, you'll be able to give your objects (or someone elses) new responsibilities without making any code changes to the underlying classes. " - p. 79 | | | | "I used to think real men subclassed everything. That was until I learned the power of extension at runtime, rather than at compile time. " - p. 79 | | | | "Now that you know the Decorator Pattern, the I/O classes should make more sense since the java.io package is largely based on Decorator. " - p. 100 |
Notes on "Chapter 4: The Factory Pattern: Baking with OO Goodness":
| |
| The chapter starts out with "When you see 'new', think 'concrete'" and "what's wrong with 'new'". Ok, this is great, I know this problem, where you have a case statement inside a constructor. How to emulate object creation. Shows how to build a factory object. Nice question: "What's the advantage of this? It looks like we are just pushing the problem off to another object." I like how this book has the section "There are no dumb questions" which has the types of questions that you are glad someone else in a workshop asks because you had exactly the same question. They work through an example of a Factory class which creates "pizza" objects. Parallel class hierarchies. Lots of code changes and discussions. Then you do "Abstract Factory". There is a cool interview where Head First asks the Factory and Abstract Factory to talk about each other from their own points of view.
| | | | "You'll learn that instantiation is an activity that shouldn't always be done in public and can often lead to coupling problems. " - p. 109 | | | | "Find out how Factory Patterns can help save you from embarrasing dependencies. " - p. 109 | | | | "Depend upon abstractions. Do not depend upon concrete classes. " - p. 139 | | | | "Like many of our principles, this is a guideline you should strive for, rather than a rule you should follow all the time. " - p. 143 |
Notes on "Chapter 5: The Singleton Pattern: One of a Kind Objects":
| |
| Talk between the Guru and the skeptical developer again about WHY you would want to instantiate only one instance of a class (caches, thread pools, dialog boxes, etc.), interview with a Singleton, chocolate factory example, deals with multithreading issues concerning the use of Singletons, double-checked locking.
|
Notes on "Chapter 6: The Command Pattern: Encapsulating Invocation":
| |
| Uses an example of controlling objects with a remote control, brief introduction of command pattern, show example of ordering at a diner, from the Diner to the Command Pattern, creating a command to turn the light on, mentions Null Object, shows how to implement an UNDO button, another use of command pattern: logging requests,
| | | | "We can do some wickedly smart things with these encapsulated method invocations, like save them away for logging or reuse them to implement undo in our code. " - p. 191 |
Notes on "Chapter 7: The Adapter and Facade Patterns: Being Adaptive":
| |
| They use the example of a European outlet adapter, fireside chat between object adapter and class adapter, shows how to adapt an enumeration to an iterator,
| | | | "If it walks like a duck and quacks like a duck, then it might be a turkey wrapped with a duck adapter. " - p. 238 | | | | "A Decorator converts one interface to another, an Adapter doesn't alter the interface, but adds responsibility, and a Facade makes an interface simpler. " - p. 254 | | | | "Principle of Least Knowledge: talk only to your immediate friends. " - p. 265 |
Notes on "Chapter 8: The Template Method Pattern: Encapsulating Algorithms":
| |
| Uses example of abstracting coffee and tea, but allowing the PROCESS of making them be encapsulated in the template method pattern, describes what a hook is (a method that is declared in the abstract class, but nonly given an empty or default implementation which gives the subclasses the ability to hook into the algorithm at various points; compares the Hollywood Principles ("don't call us, we'll call you") to the Template Method, discusses compareTo(), discusses JFrames in terms of the Template Method, I love the fireside chats, like the one where Template Method and Strategy compare methods,
| | | | "We're going to get down to encapsulating pieces of algorithms so that subclasses can hook themselves right into a computation anytime they want. " - p. 275 |
Notes on "Chapter 9: The Iterator and Composite Patterns: Well-Managed Collections":
| |
| Uses an example of two cooks which each have their own menu with different internal implementations (one Array and one ArrayList), it turns out that they both just have to add the createIterator() method, then they do the Composite Pattern, discusses the Null Iterator (an iterator that always returns false when hasNext() is called), shows how Iterator and Composite work together, an interview with the Composite pattern.
| | | | "You're going to see how you can allow your clients to iterate through your objects without ever getting a peek at how you store your objects. " - p. 315 | | | | "Separating responsibility in design is one of the most difficult things to do. " - p. 339 | | | | "In Java 5 they've added support for iterating over Collections so that you don't even have to ask for an iterator. " - p. 349 |
Notes on "Chapter 10: The State Pattern: The State of Things":
| |
| Example is a gumball controller (e.g. take quarter, etc.), then you get a change request: one in every ten times someone buys a gumball they should get two instead of one, apparently you give the responsibility of STATE to another class which maintains state for other object, there is a conversation between the Strategy and State patterns,
| | | | "A little known fact: the Strategy and State Patterns were twins separated at birth. " - p. 385 | | | | "The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class. " - p. 410 |
Notes on "Chapter 11: The Proxy Pattern: Controlling Object Access":
| |
| The CEO of the gumball company needs to monitor his gumball machines REMOTELY, hence the need for a proxy; talks about Java RMI (remote method invocation), shows when you would need a Virtual Proxy, e.g. when you have to retrieve a CD cover over the Internet and it takes time, so you hvae a virtual proxy act as they object until it is instantiated, chat between proxy and decorator patterns. Discusses invocation handlers,
| | | | "That's what proxies do: control and manage access. " - p. 429 | | | | "Use the Proxy Pattern to create a representative object that controls access to another object, which may be remote, expensive to create or in need of securing. " - p. 460 | | | | "The Virtual Proxy often defers the creation of the object until it is needed; the Virtual Proxy also acts as a surrogate for the object before and while it is being created. " - p. 462 |
Notes on "Chapter 12: Compound Patterns: Patterns of Patterns":
| |
| Example of how to count quacks in a flock of ducks in which they use the Adapter, Decorator, Abstract Fctory, Composite, Iterator and Observer; discusses Model-View-Controller, then they "look at teh MVC through patterns-colored glasses, this is a good chapter to see how patterns work together and to learn MVC.
| | | | "Some of the most powerful OO designs use several patterns together. " - p. 499 | | | | "I've tried learning MVC before and it made my brain hurt. " - p. 528 |
Notes on "Chapter 13: Better Living with Patterns: Patterns in the Real World":
| |
| Talks about how to create patterns, e.g. a "Hello World" pattern, discusses anti-patterns, e.g. "The Golden Hammer"
| | | | "Next time someone tells you a pattern is a solution to a problem in a context, just nod and smile. " - p. 579 | | | | "Only when a solution balances dboth sides of the force (the light side: your goal, and the dark side: the constratins) do we have a useful pattern. " - p. 582 | | | | "Patterns are discovered, not created. " - p. 586 | | | | "WARNING: Overuse of design patterns can lead to code that is downright over-engineered. Always go with the simplest solution that does the job and introduce patterns where the need emerges. " - p. 598 | | | | "Patterns are tools not rules -- they need to be tweaked adn adapted to your problem. " - p. 601 |
Notes on "Chapter 14: Appendix: Leftover Patterns":
| |
| Gives two-pages for each of the remaining patterns: Bridge, Builder, Chain of Responsibility, Flyweight, Interpreter, Mediator, Memento, Prototype, and Visitor.
|
| 
order from
Amazon.com
order from
Amazon.de
| Head First Design Patterns
by Eric Freeman
You want to learn about the patterns that matter--why to use them, when to use them, how to use them (and when NOT to use them). But you don't just want to see how patterns look in a book, you want to know how they look in real world applications. You'll learn why Singleton isn't as simple as it sounds, how the Factory is so often misunderstood, or on the real relationship between Decorator, Facade and Adapter. Head First Design Patterns will load patterns into your brain in a way that sticks. In a way that lets you put them to work immediately. In a way that makes you better at solving software design problems, and better at speaking the language of patterns with others on your team.
|
Cool things about this book:- AFTER understanding and solving the problem, you are then told WHICH design pattern you used, i.e. Strategy Pattern. Nice introduction.
- Nice conversation between a "skeptical developer" and a guru.
- I like how they use simplified UML diagrams.
- First you take a "misguided swag" at the problem, you discuss why it fails, then they show you how to do it right.
- I really like their conversations, e.g. the cubicle conversation: the characters ask nice, pointed questions.
- Fireside chat between Subject and Observer.
- "Confessions of a Decorator" interview.
- I like how this book has the section "There are no dumb questions" which has the types of questions that you are glad someone else in a workshop asks because you had exactly the same question.
- There is a cool interview where Head First asks the Factory and Abstract Factory to talk about each other from their own points of view.
- Deals with multithreading issues concerning the use of Singletons.
- Shows how to implement an UNDO button.
- Shows how to adapt an enumeration to an iterator.
- Discusses JFrames in terms of the Template Method.
- I love the fireside chats, like the one where Template Method and Strategy compare methods.
- Shows how Iterator and Composite work together.
- There is a conversation between the Strategy and State patterns.
- Shows when you would need a Virtual Proxy, e.g. when you have to retrieve a CD cover over the Internet and it takes time, so you hvae a virtual proxy act as they object until it is instantiated.
- Example of how to count quacks in a flock of ducks in which they use the Adapter, Decorator, Abstract Fctory, Composite, Iterator and Observer.
- Discusses Model-View-Controller.
- They "look at teh MVC through patterns-colored glasses.
- Talks about how to create patterns, e.g. a "Hello World" pattern.
- Discusses anti-patterns, e.g. "The Golden Hammer".
Table of Contents:- Introduction
- Chapter 1: Welcome to Design Patterns
- Chapter 2: The Observer Pattern: Keeping your Objects in the Know
- Chapter 3: The Decorator Pattern: Decorating Objects
- Chapter 4: The Factory Pattern: Baking with OO Goodness
- Chapter 5: The Singleton Pattern: One of a Kind Objects
- Chapter 6: The Command Pattern: Encapsulating Invocation
- Chapter 7: The Adapter and Facade Patterns: Being Adaptive
- Chapter 8: The Template Method Pattern: Encapsulating Algorithms
- Chapter 9: The Iterator and Composite Patterns: Well-Managed Collections
- Chapter 10: The State Pattern: The State of Things
- Chapter 11: The Proxy Pattern: Controlling Object Access
- Chapter 12: Compound Patterns: Patterns of Patterns
- Chapter 13: Better Living with Patterns: Patterns in the Real World
- Chapter 14: Appendix: Leftover Patterns
 | link |  | note | | quote |  | acronym |  | typo |  | flashcard |  | question |
|
|
|
