Separating Logic/GUI and user interaction

imagine you have a function that creates/copies/moves files. [logic]

For the case that a file that should be copied/created already exists you would like to ask the user to overwrite the file or not.[(G)UI]

What is your approach to implement this if (G)UI and logic are completely separated开发者_StackOverflow?

The first thing that comes into my mind would be the MVC-pattern, but this means that I would have to use it whereever I need user interaction.

Any other suggestions?

BTW: How would you implement this in non-OO-languages?

If GUI and logic are really separated, then this question should never arise. The program should, by design, either overwrite or not overwrite based on an option which has a default value. If the GUI is available, the option can be set.

In fact, although the obvious approach is to just have at it and begin copying, you could make a first pass looking for conflicts, and checking that the target device has enough free storage. Then, if there is a problem, terminate by doing nothing, unless there is a GUI in which case you can report the problem and ask whether to proceed anyway.

If you want to have a design in which the GUI can be invoked on a file by file basis, then design the logic around that as a set of n processes each of which copies one file, and has an optional GUI available in the error reporting section. The GUI can then reinvoke the copy-one-file logic.

I can see two ways:

• You have two functions, file_exists(...) and copy_file(...). The UI side always calls file_exists first and asks the user whether to copy the file is it already exists.
• You have only one function copy_file(bool force, ...), that by default fails if the file exists. So UI side calls the default version of the function, check if it failed and why, if it was because the file already exists, ask the user and try again with force=true.

In a Non OO language I would implement some kind of event queue where the parent (or child, depending on your design) UI polled for events while a 'busy' flag was true. Such an event lets the other side do other work while waiting for a 'they answered' flag to come true. Of course, some timeout in both directions would have to be observed as well as mutual exclusion. Basically, imply the principles of non-blocking I/O or your favorite theory on practical lock free programming here.

There are degrees of separation .. processes can communicate. Depending on your language of choice, you have shared memory segments, semaphores .. or IPC via relational DB with primitive signals. Its hard to be more specific with such a generic question.

See my comment, a little more information is needed so an answer can be crafted that works within your language of choice.

The first thing that comes into my mind would be the MVC-pattern, but this means that I would have to use it wherever I need user interaction.

And this is a bad thing why? Separating GUI and logic is exactly what the MVC pattern is for. Don't be scared of it just because it a has a long name -- as soon as you've separated GUI and logic you have a "view" and a "controller", at least, if not a "model" -- and if your application has state, you've got a model too. You just may not have admitted it to yourself yet.

From what I can see, there are really two problems:

1. We have an algorithm (logic) in which we would like to defer some operations and decisions to something else (e.g. user via UI).
2. We would like to avoid tight coupling between the algorithm and that something else.

If we use OO languages, there are several design patters which address these two specific problems.

• Template Method pattern can solve #1. It does not solve #2 very well because the typical implementation is via inheritence.
• Observer pattern looks promising too.

So really it is choosing and mixing the simplest one for the needs and most suitable for the language.

In practical terms, if talk about C# for example, we can implement Template Method and Observer hybrid like this:

// This will handle extensions to the FileCopy algorithm
abstract class FileCopyExtention
{
 public abstract Response WhatToDoWhenFileExists();
}


// the copy function, pure logic
public static void Copy(string source, string destination, FileCopyExtention extension) 
{
 if (File.Exists(destination))
 {
  var response = _extension.WhatToDoWhenFileExists();
  if (response == overwrite)
   // overwrite the file
  else
   // error
 }
}

// This is our user-interactive UI extension
class FileCopyUI : FileCopyExtention
{
 public override Response WhatToDoWhenFileExists()
 {
  // show some UI, return user's response to the caller
 }
}

// the program itself
void Main()
{
 Copy("/tmp/foo", "/tmp/bar", new FileCopyUI());
}

As a variation of the theme, you can use events, delegates or whatever the language of your choice provides.

In C, this could be a function pointer, in C++ a reference to a class I guess.

What about this approach [pseudo-code]:

UIClass
{
    //
    // Some code
    //

    bool fileCopied = false;

    do {
        try {
            fileCopied = CopyFile(fileName);
        } catch (FileExists) {
            //
            // Ask "File exists! Overwrite?" If "No", exit do-loop
            //
        } catch (FileLocked) {
            //
            // Ask "File Locked! Repeat?",   If "No", exit do-loop
           //
        } catch (etc...) {
            //
            // etc.
            //    
        }
    } while (!fileCopied);

    //
    // Some code
    //
}

LogicClass
{
    //
    // Some code
    //

    bool CopyFile(string fileName)
    {
        //
        // copy file
        //
    }

    //
    // Some code
    //

}