3
\$\begingroup\$

I'm working on making a shortcut... manager, if you will. It will be reused throughout the rest of the application for registering types that can later be resolved into views. I have a rule that the shortcuts need to be able to be grouped by their different purposes throughout the application. For instance, if I have shortcuts for car related stuff and then shortcuts for truck related stuff I would need them sorted.

This is what I have come up thus far. Thoughts, comments, and suggestions on changing this to make it better would be appreciated.

public static Shortcuts
{
    public enum ShortcutType
    {
        Car, Truck
    }

    static Shortcuts
    {
        AllShortcuts = new Dictionary<string, Type>();
        CarShortcuts = new Dictionary<string, Type>();
        TruckShortcuts = new Dictionary<string, Type>();
    }

    public static Dictionary<string, Type> AllShortcuts { get; private set; }
    public static Dictionary<string, Type> CarShortcuts { get; private set; }
    public static Dictionary<string, Type> TruckShortcuts { get; private set; }

    public static void AddShortcut(KeyValuePair<string, Type> kvp, ShortcutType type)
    {
        switch(type)
        {
            case ShortcutType.Car:
                CarShortcuts.Add(kvp.Key, kvp.Value);
                break;
            case ShortcutType.Truck:
                TruckShortcuts.Add(kvp.Key, kvp.Value);
                break;
        }

        if (!AllShortcuts.Contains(kvp))
        {
            AllShortcuts.Add(kvp.Key, kvp.Value);
        }
    }

    public static void RemoveShortcut(KeyValuePair<string, Type> kvp, ShortcutType type)
    {
        switch(type)
        {
            case ShortcutType.Car:
                if (CarShortcuts.Contains(kvp))
                {
                    CarShortcuts.Remove(kvp.Key);
                }
                break;
            case ShortcutType.Truck:
                if (TruckShortcuts.Contains(kvp))
                {
                    TruckShortcuts.Remove(kvp.Key);
                }
                break;
        }

        if (AllShortcuts.Contains(kvp))
        {
            AllShortcuts.Remove(kvp.Key);
        }
    }
}
\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

Here are some thoughts to ponder:

  • If you are to access a car short cut, then you would need to know:
    (i) that you want to get a car short cut, and
    (ii) you would have to call the relevant property, and
    (iii) presumably you’d have to enumerate till you found the shortcut of your choice.
  • There seems to be some duplication: values are being stored in at least two dictionaries:
    (i) either the car or truck short-cut dictionary and
    (ii) the Allshortcuts dictionary – is there are reason for this duplication? If you don’t know where the short cut is, then there are only two possible choices: it’s either in the truck dictionary or the car dictionary. You could possibly write a method if you really wanted which searches both the dictionaries and returns the appropriate value.
  • Since you have access directly to the dictionaries as properties – then why have a AddShortCut and RemoveShortCut method – you can directly access the dictionary via the property. Sure an OOP diehard might insist on you using a getter method – but you still have one location, one point of all when accessing those dictionaries via the property.
  • Is there any reason to have a static class?

Something like this may be easier.

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading.Tasks;

namespace practiceConsole
{///
    internal class Program
    {
        #region public properties and variables

        private Dictionary<string, Type> _truckShortCuts = new Dictionary<string, Type>();

        public Dictionary<string, Type> TruckShortCuts
        {
            get { return _truckShortCuts; }
            set { _truckShortCuts = value; }
        }

        private Dictionary<string, Type> _carShortcuts = new Dictionary<string, Type>();

        public Dictionary<string, Type> CarShortCuts
        {
            get { return _carShortcuts; }
            set { _carShortcuts = value; }
        }

        #endregion public properties and variables

        private static void Main(string[] args)
        {
        }

        public Type GetShortCut(string key)
        {
            Type truckValue;
            if (TruckShortCuts.TryGetValue(key, out truckValue))
            {
                return truckValue;
            }
            else
            {
                // couldn't find the key in trucks.
                // so let's search for it in Cars

                Type carValue;
                if (CarShortCuts.TryGetValue(key, out carValue))
                {
                    return carValue;
                }
                else
                {
                    // couldn't find the key.
                    // throw exception
                    throw new KeyNotFoundException("\nCouldn't find the key in either the car or trucks shortcut dictionaries, my regrets.");
                }
            }
        }
    }
}
\$\endgroup\$
2
  • \$\begingroup\$ The reason I chose to add the enumeration is because when a user decides to add shortcuts they'll be brought to something of a maintenance menu. And in that i'd like to be able to sort by what the shortcuts are related to(since there will be a bunch. Say 10 for car, 10 for truck, 10 for x, 10 for y, and on). My reasoning for adding the add() and remove and only having a getter is based on top of that. it forces the use of a certain type rather than adding something all nimbly bimbly. I do agree though it's not a good idea to store all and seperate lists, so i've changed that. \$\endgroup\$
    – Marsh
    Commented Oct 26, 2017 at 15:01
  • \$\begingroup\$ I created the static class because it didn't make sense to instantiate multiple instances of the Shortcuts class. \$\endgroup\$
    – Marsh
    Commented Oct 26, 2017 at 15:02

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.