Article:		Agile Software Development: Principles, Patterns,and Practices -- The Adapter Pattern
Subject:		Just some comments.....
Date:		2004-08-19 05:38:16
From:		andyd
Hi Robert. Intersting Article. Just some comments: I always thought that the 3rd case in your article (titled sender's protocol) was the adapter pattern. I've never seen the other cases as adapters. I'm just wondering.. why did you decide to call them adapters as well? I've always seen the adapter pattern as changing the behavour of a class so that it complies with a common interface (and a common behavour) My analogy for the adapter pattern (a british analogy being a brit) is the US to UK power adapter that you can buy in, "all good retailers" (yes, I've worked in the states!): it converts from 110v to 240v so that US appliances look like UK devices for the UK power socket! So, the US device is adapted to look like a UK device as far as the plug is concerned! On a tangent; small point: shouldn't the ThreeWay light adapter set the light on (if not on) not make the light brigher. Isn't the method breaking the Liskov subistution principle? If you call turnOn, shouldn't the method turn on the light, not make it brighter if it's on??? Finally, just a note. In the example, isn't Button a redundant class? The light can switch itself on and off! You don't need a button to do that (just as a credit card doesn't need a credit card swiper - its a physical limitation as Riel once said in OO heuristics). Maybe a better example would be "room as many lights" - each light may have a different interface that you need to adapt so that the room can turn them on or off without knowing about lots of different light interfaces (??? may be not!). Room would have a method, turnOnLights(). which would call the adapter to switch on each light. Just my 2 cents. Hopefully, the comments may be useful to somebody! Cheers Andy