Should I just move the file or create a class which moves it?

Question

Okay, I got this small program which tags (as in ID3v2.4 etc.) some music files. Now I want the user to have the option to move and/or rename those tagged files if he/she wishes to.

Considering that I am trying to keep a fairly clean and loosely coupled design in this system (even though extensibility is not really important here, it's just fun), would you just call someFileInfoObject.Move(someWhere) where someWhere is the applied pattern or would it be wise to implement some classes - maybe MoveFileStrategy, RenameFileStrategy (I know that moving/renaming can be considered the same in some systems, but I want them to be enabled separately) - which figure out the destination and whether the strategy should be applied when an Apply(FileInfo file) method or so is called.

If you think that some strategy classes may be useful, do you have any suggestion on a good implementation strategy?

As already said, over-engineering is not really an issue here, because it is a fun project mainly targeted at getting some programming and engineering practice. :)

Answer 1

You can make the case that you have a virtually unlimited number of commands for your files. Think of this class hierarchy.

Command
    CopyCommand
    RenameCommand
    MoveCommand
    DiffCommand
    CompressCommand

These aren't really strategies. They're just ordinary classes with a simple "execute" method. You provide the options and arguments through ordinary setters. Then you execute the method.

This borrows from Ant's design pattern for Tasks that can be plugged in.

Answer 2

Off the top of my head, building on @S.Lott, keep the commands themselves simple and atomic, and create a command queue. The UI add's commands to the queue, and the program executes the commands sequentially.

Additionally, you could hang onto (memento's) of executed commands and provide an undo facility.