tag:blogger.com,1999:blog-8855100053469796720.post8899364269948861376..comments2022-12-04T07:40:03.661+00:00Comments on Making Ripples: Not A Polymorphic Methoddanhttp://www.blogger.com/profile/03526045555222015549noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-8855100053469796720.post-70757351775443946012014-10-21T21:17:02.957+01:002014-10-21T21:17:02.957+01:00I returned to this code today. I'd hit a point...I returned to this code today. I'd hit a point where I wanted to render for two different size outputs. I didn't want a radically different rendering, such as different symbols and colour schemes or different meaning to line widths, which would imply a new set of classes. But, with one output much larger than the other a given set of line widths etc looked right for one output and hard to read and spidery for the other! The solution was to bundle the size-related parameters up into a new class and decorate the renderer with them. Refactoring the existing constants out and creating the (couple of) rendering objects with the sizing objects hit several classes and several test cases, but was done in a couple of pain-free refactoring passes. For extra tidiness the sizing class also describes the size of the image to render - the information is needed in more or less the same place as the rendering objects are created - and it couples the various canvas and feature sizing together in quite an agreeable way.danhttps://www.blogger.com/profile/03526045555222015549noreply@blogger.com