Design Patterns Explained: A New Perspective on Object Oriented Design, 2nd Edition (Software Patterns)
4.1
Review Date:
Comments
by anonymous 2017-08-20
Composition would be the right design decision; do not inherit.
If you have a special type of button that can be reused, create one: class MyButton : public CButton
If MyButton need access to methods from CMyDialogEx and CMyWnd, extract the common methods in a virtual class (strategy pattern) and derive from it. You can use the MyButton's constructor to place the instance of virtual class, so MyButton's methods can access the real implementation.
Are there other patterns not mentioned in these books?
Definitely. The GoF patterns are kind of the grandaddies of it all, and fairly general, but you can have domain-specific patterns too. Like Fowler's PoEAA, as you mentioned. Or design patterns for embedded systems. But also more domain-specific than that, like Fowler's book on Analysis Patterns, which has financial and health care related patterns. Or patterns for avionics systems, like in the link available here at the Hillside Patterns Catalog.
What is its origin?
If you mean what is the origin of the Delegation pattern, I dunno, but someone has asked a similar question here.
Are there other "must read" books or online resources on this topic?
The amusingly-named "PLoP" conferences (Pattern Languages of Program Design) are the first place a fair few patterns are aired I believe.
I found Design Patterns Explained to be quite useful in explaining some of the original thinking behind the Gang of Four patterns. It's an explanation as opposed to a reference.
In addition to the PluralSight catalog mentioned elsewhere, NetObjectives have some great resources on patterns (and principles in general), particularly their series of webinars.
Composition would be the right design decision; do not inherit.
If you have a special type of button that can be reused, create one:
class MyButton : public CButtonIf
MyButtonneed access to methods fromCMyDialogExandCMyWnd, extract the common methods in a virtual class (strategy pattern) and derive from it. You can use theMyButton's constructor to place the instance of virtual class, so MyButton's methods can access the real implementation.I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):
It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.
Definitely. The GoF patterns are kind of the grandaddies of it all, and fairly general, but you can have domain-specific patterns too. Like Fowler's PoEAA, as you mentioned. Or design patterns for embedded systems. But also more domain-specific than that, like Fowler's book on Analysis Patterns, which has financial and health care related patterns. Or patterns for avionics systems, like in the link available here at the Hillside Patterns Catalog.
If you mean what is the origin of the Delegation pattern, I dunno, but someone has asked a similar question here.
The amusingly-named "PLoP" conferences (Pattern Languages of Program Design) are the first place a fair few patterns are aired I believe.
There's a PLoP journal as well: Transactions on Pattern Languages of Programming.
I found Design Patterns Explained to be quite useful in explaining some of the original thinking behind the Gang of Four patterns. It's an explanation as opposed to a reference.
In addition to the PluralSight catalog mentioned elsewhere, NetObjectives have some great resources on patterns (and principles in general), particularly their series of webinars.
I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):
It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.