No thanks for sharing.
DRY does not pay off in large codebases and this tutorial overly simplifies the case.
Let's say there are some backend endpoints and they are using nested objects inside JSON schema. It is perfectly fine to duplicate POJO objects when reading. If we are coding a mobile client and we work simultaneously with backend team, then it is better to adapt response in one place, than using the same shared object in others. Some response might change and this will require the whole POJO to be split and refactored.
Let's say we use the same function in many classes. The only solution is to use the composition and wrap the function in a class and pass it as dependency.
More shared code = more coupling.
You forgot about a more important rule - make codebase easy to extend, not modify - the Open/Closed Principle. Simple DRY is not enough and is an oversimplification.