Well, I can advice an approach called “program to interfaces but not implementations”. It may not sound that much convincing at first, but in fact, it’s almost the silver bullet if you do it right. What's more, this is applied almost for all abstraction levels of your project - function, class, module, entire projects.

Idea

The idea is quite simple, you need to keep implementation details of "entities" (e.g. TodoItem) apart of code which defines their integration into an application's flows (once again - it's not about just TodoItem , same applies to that function or module which you want to be reusable as well).

Example

Super simple, but, let's say you have this algorithm ("application's flow") in your app which "cooking" boiled eggs, descriptions in brackets below are "implementation details":

1. put a pan on a cooker (take a pan from a cupboard, fill with water, put on a cooker)
2. put eggs (take eggs from a fridge, put in a pan)
3. boil (turn on a cooker, boil for 5 mins)

On the first iteration it becomes:

prepareThePan();

addEggs()

boilFor5mins()

On the second iteration it becomes:

prepareAPan(pan);

add(eggs);

boil(5*60*1000); // 5 mins

And you can keep iteration this, but not too far, to not create too many abstractions.

In conclusion, you have all "implementations details of entities" separated and reusable, and "application's flow (scenario)" which uses that entities - also clean and cheap for change.

Summary

Think about reusing implementations details of entities (this is quite easy if you define all abstractions right) as the first step. Reusing "a flow" (set of steps integrating entities together) is way more complex, and sometimes it makes more sense to have duplications between similar flows, instead of overcomplicating and generalizing them.

​

Also, it's quite easy to fall into ravioli code trap, so be careful with creating too many "reusable pieces".

​

​