Central Access Refactor

I wanted to ensure the central access to the tasks would work.  In my other blog, I talked about centralized access in a windows application, where the root object could be accessible through the entire application.  I created the following class:

namespace Reminder.ObjectModel
{
    public class ReminderManager
    {
        private static readonly ReminderManager _instance = new ReminderManager();
        private TaskCollection _tasks = null;


        #region " Properties "

        public static ReminderManager Instance
        {
            get { return _instance; }
        }

        public static TaskCollection Tasks
        {
            get { return Instance._tasks; }
        }

        #endregion



        #region " Constructors "

        public ReminderManager()
        {
            _tasks = new TaskCollection();
        }

        #endregion
    }
}

This provides central access through the Instance property, statically instantiated above (explained in other post).  The TaskCollection is made available through this, and so it will be available through the application.  I wanted to test this functionality, so I wrote two tests, a second test to also check whether a task is added successfully:

[TestFixture()]
public class GlobalAccessTest
{
    [Test()]
    public void TestGlobalAccess()
    {
        Assert.IsNotNull(MGR.Instance);
        Assert.IsNotNull(MGR.Tasks);
    }

    [Test()]
    public void TestAddTask()
    {
        Task task = new Task("Test");
        MGR.Tasks.Add(task);

        Assert.IsTrue(MGR.Tasks.Count == 1);
    }
}

Both of these tests succeeded, so on with development.  I had to modify the TaskCollection collection to add a TaskAdded and TaskRemoved events, so when an item is added/inserted, the TaskAdded event fires; when removed, the TaskRemoved event fires.  Because I moved the Tasks collection out of MainForm (wrapper form), I removed two methods because they weren't needed anymore.  I was also able to remove these from Tasks, replacing them with event handlers as such:

void Tasks_TaskAdded(object sender, DataEventArgs<Task> e)
{
    Task task = e.Data;
    ListViewItem item = new ListViewItem();

    item.Text = task.Name;
    item.SubItems.Add(task.Attributes["IsReoccurring"].GetValue<bool>().ToString());
    item.SubItems.Add(task.Attributes["DueDate"].GetValue<DateTime>().ToShortDateString());
    //Assign the task object to the item's tag property, for safekeeping
    item.Tag = task;
    //Add the item to the view
    this.lvTasks.Items.Add(item);
}

void Tasks_TaskRemoved(object sender, DataEventArgs<Task> e)
{
    ListViewItem item = this.FindByTag(e.Data);
    //If the item exists, remove it from the list
    if (item != null)
        this.lvTasks.Items.Remove(item);
}

These were previously manual method calls; now, they occur automatically upon adding/removing tasks.  I also utilized an event handler to store the data through a generic value:

public class DataEventArgs<T> : EventArgs
{
    private T _data;



    #region " Properties "

    public T Data
    {
        get { return _data; }
    }

    #endregion



    #region " Constructors "

    public DataEventArgs(T data)
    {
        _data = data;
    }

    #endregion
}

public delegate void DataEventHandler<T>(object sender, DataEventArgs<T> e);

This allows me to quickly setup a custom event handler.  This event handler is very useful for storing custom objects, where only one data parameter is needed.

After this refactoring, less code was used and I removed some methods, which is always beneficial, especially when the methods weren't used anymore.  It helps to keep the simplicity of the applications as well. 

Comments

No Comments