Implementation Language Matters
Stuart Halloway recently wrote that Design Patterns are Code Smells and emphasized that implementation language matters. While Stuart is specifically talking about design patterns, this applies to design in general.
"Speaking" a programming language is like speaking any other language. One major difference though is that while you don't often see for example an English speaker who insists on trying to speak French with an English sentence structure, you quite often see practitioners more familar with one computer language try to apply that language's idioms to every language they know. In my experience these are quite often former C++ types who insist on speaking Java, and every other language they know, with a strong C++ accent, particularly when it comes to design. I'm sure the same holds true for many long-time Java developers crossing over into Rails or some other language. The design idioms valid in one language are not necessarily valid in another.
I had a former long-time C++ turned Java developer recently state matter-of-factly to me that design and language are independent. This may be the case from a theoretical, academic or ivory tower standpoint, but it's not the case down in the trenches. The pallet of language and technologies used for implementation has a profound effect on application design. Certain frameworks for example often encourage particular design idioms that you may not follow had your choice of technology been different.
As an example, Java designs often rely quite heavily on Java interfaces. We do this for several reasons including some that are immediately practical. Decoupling dependencies and abstracting them with interfaces is generally considered a good practice, but a very practical reason for doing this is to better facilitate unit testing with mock objects. This is a bit foreign to many in the C++ world who are quite happy to spend their time in the debugger and consider such abstractions as over-engineering.
I agree with Stuart and think he hit the nail on the head regarding design patterns and language. But just as implementation language matters as far as design patterns go, there is clearly something in our choice of language and technologies that encourages certain designs in general. Design and language are not independent.
"Speaking" a programming language is like speaking any other language. One major difference though is that while you don't often see for example an English speaker who insists on trying to speak French with an English sentence structure, you quite often see practitioners more familar with one computer language try to apply that language's idioms to every language they know. In my experience these are quite often former C++ types who insist on speaking Java, and every other language they know, with a strong C++ accent, particularly when it comes to design. I'm sure the same holds true for many long-time Java developers crossing over into Rails or some other language. The design idioms valid in one language are not necessarily valid in another.
I had a former long-time C++ turned Java developer recently state matter-of-factly to me that design and language are independent. This may be the case from a theoretical, academic or ivory tower standpoint, but it's not the case down in the trenches. The pallet of language and technologies used for implementation has a profound effect on application design. Certain frameworks for example often encourage particular design idioms that you may not follow had your choice of technology been different.
As an example, Java designs often rely quite heavily on Java interfaces. We do this for several reasons including some that are immediately practical. Decoupling dependencies and abstracting them with interfaces is generally considered a good practice, but a very practical reason for doing this is to better facilitate unit testing with mock objects. This is a bit foreign to many in the C++ world who are quite happy to spend their time in the debugger and consider such abstractions as over-engineering.
I agree with Stuart and think he hit the nail on the head regarding design patterns and language. But just as implementation language matters as far as design patterns go, there is clearly something in our choice of language and technologies that encourages certain designs in general. Design and language are not independent.