Comments on: living code http://malvasiabianca.org/archives/2008/10/living-code/ Thu, 24 May 2012 20:46:05 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: David Carlton http://malvasiabianca.org/archives/2008/10/living-code/comment-page-1/#comment-114290 David Carlton Mon, 27 Oct 2008 23:02:38 +0000 http://malvasiabianca.org/?p=1185#comment-114290 Hmm, good examples. They seem to have a similar flavor, but I'm having a hard time putting my finger on it. At first I thought they were simply glue classes, hooking up requests with some other object, but I'm now not confident that that's right: e.g. Strategy exists to answer somebody else's questions, but you can design a perfectly good Strategy object that can answer questions itself (instead of forwarding them to somebody else). Visitor's a fun one - if you take a broad enough point of view, I think a traditional Unix program to be used in a pipeline is a Visitor of sorts? But that's neither here nor there, I suppose. Anyways, I can imagine a Visitor with a broader interface (e.g. one where you actively grab output), but I can also imagine a Visitor that just shoves data from here to there and doesn't need any configuration beyond its constructor. Hmm, I'll have to think about this more; you've certainly convinced me that, in some circumstances, having the public concrete interface exactly match an abstract interface can be quite reasonable. Hmm, good examples. They seem to have a similar flavor, but I’m having a hard time putting my finger on it. At first I thought they were simply glue classes, hooking up requests with some other object, but I’m now not confident that that’s right: e.g. Strategy exists to answer somebody else’s questions, but you can design a perfectly good Strategy object that can answer questions itself (instead of forwarding them to somebody else).

Visitor’s a fun one – if you take a broad enough point of view, I think a traditional Unix program to be used in a pipeline is a Visitor of sorts? But that’s neither here nor there, I suppose. Anyways, I can imagine a Visitor with a broader interface (e.g. one where you actively grab output), but I can also imagine a Visitor that just shoves data from here to there and doesn’t need any configuration beyond its constructor.

Hmm, I’ll have to think about this more; you’ve certainly convinced me that, in some circumstances, having the public concrete interface exactly match an abstract interface can be quite reasonable.

]]> By: Joe Pallas http://malvasiabianca.org/archives/2008/10/living-code/comment-page-1/#comment-114281 Joe Pallas Mon, 27 Oct 2008 21:12:37 +0000 http://malvasiabianca.org/?p=1185#comment-114281 You asked, "Are there many good examples where you have multiple concrete classes that all support the same abstract interface, and where they don’t add methods of their own?" I think the answer is yes, and I would offer at least Strategy, Proxy, and Visitor from Design Patterns. You asked, “Are there many good examples where you have multiple concrete classes that all support the same abstract interface, and where they don’t add methods of their own?” I think the answer is yes, and I would offer at least Strategy, Proxy, and Visitor from Design Patterns.

]]>