How can such a simple method be broken down and named?

Question

Best practices dictate continuously that a method should be responsible for only one thing. I have come across a method that does 3 things, and I dont know how to 1. decompose it according to best practices. 2. name it. Also I wonder how many methods in real life really do just one thing as text books advise all the time?

method ( entryId ) {
   if (this.checkDuplicate(entryId)) {
       this.deleteDuplicate(entryId);
       return true;
   } else {
       return false;
   } 
}

As we can see that method named method, is doing more than just one thing. Is it even possible to abide by 'method should be responsible for only one thing rule' ?

If yes, how can the above algorithm be decomposed into it ?

If not, what can I name a method that does so many things ?

you may be looking to deep into this, you're basically saying if statements should never be used. What you should be asking yourself is does the `method` function name only do one thing? You don't want a method that does UpdateDataBase & send email for example. — dbarnes, Jul 10 '15 at 22:45
Technically this method shouldn't even exist, since `deleteDuplicate(entryId)` should check if there is even something to delete! If you keep this method this way `checkDuplicate(entryId)` gets called twice: by the method and deleteDuplicate — engineercoding, Jul 10 '15 at 23:46

score 0 · Answer 1 · answered Jul 11 '15 at 00:25

Let's put it this way - that rule (GRASP - High Cohesion pattern) is not about your programming language semantic or syntax. Instead it means that you have to be careful with your methods/classes responsibilities from more like a functional or business logic standpoint. Pretty much all of the design principles have to applied in very careful and mindful fashion or you'll end up with dozens and dozens of indirections and abstract layers with no real purpose.

score 0 · Answer 2 · answered Jul 11 '15 at 00:43

While what Yauheni Maltsau wrote is true, I like to add my 10 cents.

I'd say that your method is actually doing only 1 thing: check for duplicate and delete it. So I'll keep it like this except for the name. You should give it a more descriptive name like removeIfDuplicate or something along those lines.

score 0 · Answer 3 · answered Jul 11 '15 at 00:52

You don't necessarily have to start with a perfect name and perfect cohesion. If you have unit tests to verify the behavior of the code, you can refactor in several phases, and you may end up changing the name several times over the course of the refactoring. The idea is to improve things gradually without breaking anything.

I'd probably start by naming the method "deleteEntryIfDuplicate", and I'd ask myself why the method needs to return a boolean. Since I don't have the calling code that uses the boolean, I can only speculate, but there may be a responsibility that is not handled in the right place. Maybe instead of returning a boolean, all the functionality for the case of a duplicate entry should be handled in a single method that does the deletion, logs it, and notifies listeners, for example. This may seem like adding responsibilities, but managing the case of a duplicate entry can be considered as 1 responsibility. Baking a cake is a single responsibility, even if it means you need to take the eggs and milk out of the fridge, take the flour and sugar out of the pantry, preheat the oven, etc. The goal is to have every call at the right level of abstraction.

I should add that you don't have to "gold-plate" everything. Engineering is about trade-offs. Clean code with a clear separation of responsiblities saves time and money in the long run, but you probably won't have unlimited time to polish and perfect everything.

How can such a simple method be broken down and named?

3 Answers3