To cache or not to cache



  • The software talks to some hardware device via a serial port. And that is slow, and the firmware of that device is not so safe when it comes to many queries in short intervals.

    Some properties won't change during the life time of the program, like e.g. the version of the device's hardware and firmware. Some other properties will change slowly, and with some of them it's not necessary to react immediately. So Bernie added a "caching" version of the class talking to the hardware, in addition to the non-caching version.

    public interface IHardware
    {
        string GetFirmwareVersion();
        // some other properties/commands
    }
    public class Hardware:IHardware
    {
        public virtual string GetFirmwareVersion()
        { 
            // some code for retrieving that value from the device
        }
        // etc
    }
    public class CachingHardware:Hardware
    {
        private string _CachedVersion;
        public override string GetFirmwareVersion()
        {
            if(_CachedVersion==null)
            {
                _CachedVersion=base.GetFirmwareVersion();
            }
            return _CachedVersion;
        }
    }
    

    Now comes Kevin, Bernie's MCC (most capable coworker). He was tasked with integrating the firmware updater (which was written by Bernie somewhen) into a new tool. With firmware update, the firmware version will change of course - and you cannot use the caching version. That should not be a problem at all - the team uses a simple dependency injection container, and Kevin could configure his tool to use the non-caching version, as did Bernie with the original update tool.

    Not so Kevin. He decided to change the interface:

    public interface IHardware
    {
        string GetFirmwareVersion(bool forceRead=false);
        // some other properties/commands
    }
    

    Now the client can decide if it wants to cache or not. What a great improvement! Never hide any implementation details, it is so great when you can have other parts of the software to decide.


  • Banned

    @berniethebernie sometimes, I wish boolean function arguments were illegal. Then I realize all the bad coders would work around that by using an integer in place of boolean, or even worse - a "Yes"/"No" string (case sensitive, of course!)



  • @gąska said in To cache or not to cache:

    a "Yes"/"No" string (case sensitive, of course!)

    Tsss... they are beginners in the world of WTF. Almost 20 years ago, I saw a more elegant, far better version: use localized strings for "true" and "false".

    That application was written in VB6, and there was some function

    DoSomething(Flag as string)
    If Flag="Wahr" Then
        ...
    Else If Flag="Falsch" Then
        ...
    EndIf
    

    (Not sure if I remember that syntax correctly.) When the function was called, the parameter was a boolean. VB6 "converted" it into a string automagically, using the current locale.

    Well, generally it worked. But during a test before a release, the software was installed on a Terminal Server - running on an English windows.

    I could fix that, so I remember quite well that beautiful WTF.


  • Banned

    @berniethebernie said in To cache or not to cache:

    If Flag="Wahr" Then

    0_1528278359475_477740dc-a329-4599-b062-987764e3e591-image.png



  • @gąska There is something wrong with that picture. Won't you expect the water to leave the dog at its rear end?



  • @berniethebernie

    Is this better?

    0_1528292104137_a6a5538a-5baf-4ae4-8334-d27fbf3d9187-image.png



  • @mott555 Really impressive. But the water should not be so clear there. Or has the dog been washed internally sufficiently long already?



  • @berniethebernie at that level of throughput how long do you expect it to take?


  • Notification Spam Recipient

    @berniethebernie said in To cache or not to cache:

    washed internally sufficiently long

    Oh yeah, he's gonna die within three days from that.


Log in to reply