Right now I am working on my own small project of a WPF file back up application. I have come to a point where I want to create a method that will copy files recursively from one place to another.

This is not the first time that I ask myself the question:

Should this method be a part of an existing class, or should I store it in a new class?

What bothers me the most is that if I create a new class, it will most likely consist of solely this method, so it seems like a stretch to create a whole new type for just one action. On the other hand, I believe it is a good abstraction. Copying files doesn't have much to do with a WPF window.

The example that I show here brings out a more general question. How to balance between functionality/abstraction/readability to create code where OOP principles don't obscure common sense? I am relatively new to programming, but I'd like to start following good coding practices as soon as possible, e.g. not implementing design patterns like crazy, because I have just read about them.

  • Something is a method if it needs access to a class's implementation details; otherwise it should be a function. Things that can be imported should be grouped with the things they're likely to be used with.
    – Doval
    Commented May 15, 2014 at 16:31

1 Answer 1


The main principle and purpose of OOP is to combine your data with the logic that manipulates it. Ergo, if your new method has functionality that has specifically to do with a class, then it belongs with that class.

If your recursive copy requires you to store any state in memory, like a byte queue or something like that, then make a RecursiveCopy class, and put your Copy method there. If your recursive copy method is stateless, then make it a static method, and put it in a static utility class.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.