Adapter as a design strategy
-
I've been going around in circles trying to design a new toolkit to create a certain kind of application with. What I think I'm realizing is that it's sometimes best to design classes in such a way so that they make the fewest assumptions about the environment in which they will be used. What this means from a design standpoint is that when designing a class to represent a specific concept, you do so in isolation; you make the class as cohesive as possible as a standalone entity. So where do you go once you have your finely crafted class? How do you integrate it into a context in which you are working? I think the adapter design pattern is the answer. Adapt the class so that it's interface is fitted to the rest of the application. This is a kind of bottom-up approach. And it may not seem sensible at first. But I have repeatedly found myself getting entangled in too many details when I try to consider the overall picture when designing a specific class. I'm having better luck designing classes so that they make sense on their own without any scafolding to support them. I leave the other details for later.
-
I've been going around in circles trying to design a new toolkit to create a certain kind of application with. What I think I'm realizing is that it's sometimes best to design classes in such a way so that they make the fewest assumptions about the environment in which they will be used. What this means from a design standpoint is that when designing a class to represent a specific concept, you do so in isolation; you make the class as cohesive as possible as a standalone entity. So where do you go once you have your finely crafted class? How do you integrate it into a context in which you are working? I think the adapter design pattern is the answer. Adapt the class so that it's interface is fitted to the rest of the application. This is a kind of bottom-up approach. And it may not seem sensible at first. But I have repeatedly found myself getting entangled in too many details when I try to consider the overall picture when designing a specific class. I'm having better luck designing classes so that they make sense on their own without any scafolding to support them. I leave the other details for later.
In situations like this, I would tend to look at using something like Test Driven Development and Inversion of Control and not actually design my classes in isolation - this is just acting for trouble.
Deja View - the feeling that you've seen this post before.
-
In situations like this, I would tend to look at using something like Test Driven Development and Inversion of Control and not actually design my classes in isolation - this is just acting for trouble.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
In situations like this, I would tend to look at using something like Test Driven Development and Inversion of Control and not actually design my classes in isolation - this is just acting for trouble.
Thanks, I've never given TDD a very close look. I agree that designing in isolation is not a good approach generally speaking. It may be that what I'm learning, though, is that if you have a set of low-level classes, it may be better if you can design them to make the fewest assumptions possible about the higher-level classes that will use them. Kind of postponing dealing with certain details for as long as possible. This may help reuse. What I'm struggling with is keeping higher level policies from getting entangled with the low-level algorithms that do the work. Anyway, just thinking out loud.
-
Pete O'Hanlon wrote:
In situations like this, I would tend to look at using something like Test Driven Development and Inversion of Control and not actually design my classes in isolation - this is just acting for trouble.
Thanks, I've never given TDD a very close look. I agree that designing in isolation is not a good approach generally speaking. It may be that what I'm learning, though, is that if you have a set of low-level classes, it may be better if you can design them to make the fewest assumptions possible about the higher-level classes that will use them. Kind of postponing dealing with certain details for as long as possible. This may help reuse. What I'm struggling with is keeping higher level policies from getting entangled with the low-level algorithms that do the work. Anyway, just thinking out loud.
What I'm struggling with is keeping higher level policies from getting entangled with the low-level algorithms that do the work.
if higher level polices are dependent on low-level algorithm and if low-level algorithm are changing...or if you want to make higher level polices independent of low-level algorithm then go for Strategy or Template Method.