• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Five Lines of Code: Refactoring duplication

 
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In this thread: https://coderanch.com/t/733339/engineering/Lines-Code-Readability

Christian Clausen wrote:Usually, code duplication is a hint at some unexploited structure in the code, in which case it goes away through refactoring. Rarely does this make the code smaller.


I'd like to dig into this a little deeper, particularly the "unexploited structure in the code" part.

When I think of code duplication, the DRY principle is the first thing that comes to mind and the idea that "duplication" is not about mechanical character-for-character duplication but rather the existence of the same idea/knowledge in multiple places in your code. The problem caused by this is the risk of introducing bugs when something related to the idea changes; you have to remember to change all places where that idea/knowledge is encoded to keep your program's behavior consistent. As such, Extract Method refactoring is probably the go-to technique for addressing duplicate code.

Could you expound more on the thought process behind figuring out what the "unexploited structure" is and how the refactoring goes to exploit it? Can you give a short example?
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For more context, refer to the code in this thread: https://coderanch.com/t/733396/java/arrays#3411258

Code from that thread:


Ignoring the poor data structure design choices, that code could be refactored to:

Does this example demonstrate some of the "unexploited structures" you're talking about?
 
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Junilu,

Unifying code to exploit structure is actually the entire point of chapter 5 of the book. I'll give a short teaser here: Extract method applies mostly when the duplication is inside methods which is usually when we think DRY. However another case could be where we can make two consecutive else-if bodies be equal, in which case we can join the conditions and get rid of one of the bodies, this expresses a connection between the conditions, which can then enable other refactorings. You can also have duplication in structure, such as two classes which are almost equal, which can be joined. Another case is when the control flow is duplicated, but with different method calls somewhere, in which case we can join them by utilizing a strategy pattern.

In general, I think DRY is dangerous because the mnemonic is too powerful. I've seen people get obsessed with trying to eliminate everything that looks like duplication, even when the code is supposed to be independent. There are multiple cases in which DRY is counterproductive, which I go into more detail with in a recent blog post (https://medium.com/@thedrlambda/four-games-programmers-play-but-shouldnt-21d90961b359?source=friends_link&sk=daa9a429f240d4bcabed334a1a781293). There are probably more situations when DRY is the right strategy, but we must not forget: there is no universal truth.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Christian.

I checked out Chapter 5 with the free livebook preview at Manning but ran out of my allotment for the day. I have to say though that I find the examples a little hard to follow on my IPad (12") because the before/after are side-by-side and displaying them is a little glitchy in Chrome. Aside from the livebook format glitches, the advice to avoid else with if-statements is also a bit jarring to old-timers but I know some reasons for doing so because of my experience in doing refactoring exercises where you avoid if statements altogether. However, I'm just wondering how much more difficulty a newbie will have in following the example if I'm finding  it hard to track myself.

I hope the MEAP gets added to my Manning account sooner rather than later so I can give you more detailed feedback. For selfish reasons, I really want to see your book succeed.

Thanks again for hanging out with us and answering questions.
 
Don't get me started about those stupid light bulbs.
    Bookmark Topic Watch Topic
  • New Topic