need thoughts on my interview question - .net, c#

One of the questions I was asked was that I have a database table with following columns

pid - unique identifier
orderid - varchar(20)
documentid - int 
documentpath - varchar(250)
currentLocation - varchar(250)
newlocation - varchar(250)
status - varchar(15)

I have to write a c# app to move the files fro开发者_如何转开发m currentlocation to newlocation and update status column as either 'SUCCESS' or 'FAILURE'.

This was my answer

1. Create a List of all the records using linq

2. Create a command object which would be perform moving files

3. using foreach, invoke a delegate to move the files -

4. use endinvoke to capture any exception and update the db accordingly

I was told that command pattern and delegate did not fit the bill here - i was aksed to think and implement a more favorable GoF pattern.

Not sure what they were looking for - In this day and age, do candidates keep a lot of info on head as one always has google to find any answer and come up with solution.

---

I sort of agree with Aaronaught's comment above. For a problem like this, sometimes you can overthink it and try to do something more than you actually need to do.

That said, the one GoF pattern that came to mind was "Iterator." In your first statement, you said you would read all the records into a List. The one thing that could be problematic with that is if you had millions of these records. You'd probably want to process them in a more successive fashion, rather than reading the entire list into memory. The Iterator pattern would give you the ability to iterate over the list without having to know the underlying (database) storage/retrieval mechanism. The underlying implementation of the iterator could retrieve one, ten, or a hundred records at a time, and dole them out to the business logic upon request. This would provide some testing benefit as well, because you could test your other "business" logic using a different type of underlying storage (e.g. in-memory list), so that your unit tests would be independent from the database.

---

A deep understanding of patterns is something you should definitely have as a developer - you shouldn't need to go to Google to determine which pattern to "use" because you won't have enough time to really understand that pattern between when you start reading about it and when you apply it.

Patterns are mostly about understanding forces and encapsulating variation. That is, forces create certain kinds of variation and we have well understood ways of encapsulating those kinds of variation. A "pattern" is a body of understanding about which forces lead to which kinds of variation and which methods of encapsulation best address those.

I have a friend who was teaching a course on patterns and it suddenly struck him that he could solve a given problem "using" (meaning "implementing the encapsulating technique of") every pattern in his course book. It really did a great job of helping drive home the fact that finding the right technique is more important that knowing how to apply a technique.

The Command pattern, for instance, starts with an understanding that sometimes we want to vary when something happens. In these cases, we want to decouple the decision of what to do from the decision of when to do it. In this example, I don't see any indication that when your command should be executed varies at all.

In fact, I don't really see anything that varies so there might not have been any patterns in the problem at all. If your interviewers were saying there were, then they may have some learning to do as well.

Anywho... I'd recommend Design Patterns Explained by Shalloway and Trott. You'll get a deeper understanding of what patterns are really for and how they help you do your job and, the next time they tell you that you are "using" the wrong pattern, you might just be in a position to educate them. That seems to go over pretty well for me... about 20% of the time. :)

---

I would rather say that the interviewer wanted you to use (or mention) the SOLID object oriented design principles here, and in that process you might use some design pattern.

For instance, we could a make a design like below which adheres to SRP, OCP, and DIP.

internal interface IStatusRecordsToMove
{    
    List<IRecord> Records { get; }
}

internal interface IRecord
{
    string Status { get; set; }
}

internal interface IRecordsMover
{
    ITargetDb TargetDb { get; }
    void Move(IStatusRecordsToMove record);
}

internal interface ITargetDb
{
    void SaveAndUpdateStatus(IRecord record);
}

class ProcessTableRecordsToMove : IStatusRecordsToMove
{
    public List<IRecord> Records
    {
        get { throw new NotImplementedException(); }
    }
}

internal class ProcessRecordsMoverImpl : IRecordsMover
{
    #region IRecordsMover Members

    public ITargetDb TargetDb
    {
        get { throw new NotImplementedException(); }
    }

    public void Move(IStatusRecordsToMove recordsToMove)
    {
        foreach (IRecord item in recordsToMove.Records)
        {
            TargetDb.SaveAndUpdateStatus(item);
        }
    }

    #endregion
}

internal class TargetTableBDb : ITargetDb
{
    public void SaveAndUpdateStatus(IRecord record)
    {
        try
        {
            //some db object, save new record
            record.Status = "Success";
        }
        catch(ApplicationException)
        {
            record.Status = "Failed";
        }
        finally
        {
            //Update IRecord Status in Db
        }
    }
}