Structs vs Classes

I went to lunch with a former co-worker the other day and we got into a conversation about structs vs classes. I have to admit, it has been a while since I looked into them, and I can't really remember the last time I used a struct outside of C++.  I decided to look them back up, and it seems my knowledge on the subject is a bit dated. I knew one main difference was that classes were reference types while structs were values types, but I had no idea that structs could also contain methods.  Here is a quick run down of the two types.

 Struct

  • Value Type
  • Stored on Heap
  • Does not supports Inheritance
  • Cannot have null reference unless set as Nullable
  • Less memory overhead
  • Supports Interfaces
  • Can contain Methods and Events

Classes

  • Reference Type
  • Stored on Stack
  • Supports Inheritance
  • Can be set to Null
  • Larger memory overhead
  • Supports Interfaces
  • Can contain Methods and Events

 

I think this list about sum it all up, but the main difference seems to be that one is a value type while the other is a reference type.

 

Design Patterns: Singleton

This is the first post in what I hope to be a series of posts on software design patterns. What are design patterns? Design patterns in software development are repeatable code solutions to commonly reoccurring problems. Think of them as templates to common problems that other developers have come up with to solve issues previous developers have dealt with. They help to reduce bugs and can help make your code more maintainable as it grows. Use of these patterns is considered best practices and trust me, smart people have designed them for a reason. So use them. 

Singleton Pattern

A Singleton is a class that has only one instance and provides global access to itself.  In other words, once the class in substantiated, it maintains a reference to itself, and routes all future class construction calls back to the same referenced instance. 

using System;

namespace SingletonPattern
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");

            MySingletonClass firstInstance = MySingletonClass.Instance;

            firstInstance.TestString = "This was set by firstInstance";
            Console.WriteLine($"Setting firstInstance to {firstInstance.TestString}");

            MySingletonClass secondInstance = MySingletonClass.Instance;
            Console.WriteLine($"Getting secondInstance value {secondInstance.TestString}");

            Console.ReadLine();

        }
    }

    public class MySingletonClass
    {
        private static MySingletonClass instance = null;

        public static MySingletonClass Instance
        {
            get
            {
                if(instance == null)
                {
                    instance = new MySingletonClass();
                }
                return instance;
            }
        }

        public string TestString { get; set; }
        
    }
}

Here you notice that we don't new up the MySingletonClass in main, but just set it to the instance value. The class itself will handle substantiating itself. If the value of the instance is null, then the code will new up the class and set the private instance variable to the new instance, otherwise it will just return it's referenced instance value. This is a very simple implantation and probably not the most thread-safe implementation of the pattern, but the simplest form of the pattern for learning purposes.

Here is a simple but thread-safe version of the pattern

 
public class MySingletonClass
{ private static MySingletonClass instance = null; private static readonly object myLock = new object(); public static MySingletonClass Instance { get { lock (myLock) { if (instance == null) { instance = new MySingletonClass(); } return instance; } } } public string TestString { get; set; } }

There are several other ways to go about implementing this pattern, but the basics are laid out here.  As I said in the beginning, this and other design patterns were created for good reason and we should use them. Why try and reinvent the wheel.  They help solve issues in our code so we don't have to make the same mistakes. So once again use them.

String Interpolation

We have all used the good old reliable String.Format() method, but recently I ran across the newer sleeker way of handling strings in C#. It is called "String Interpolation" and it is definitely a shortcut to constructing strings. Although string interpolation is not a new thing in itself, this implementation in C# is rather nice, once you are used to it.

 

Older Method with String.Format()

public static void OldMethod()
{
            string firstName = "John";
            string lastName = "Doe";

            var formattedString = string.Format("Hello World, My Name is {0}, {1}", firstName, lastName);
            Console.WriteLine(formattedString);
}

 

New Method using string interpolation:    

public static void NewMethod()
{
            string firstName = "John";
            string lastName = "Doe";

            var formattedString = $"Hello World, My Name is {firstName}, {lastName}";
            Console.WriteLine(formattedString);
}

 

There is nothing wrong with the older method and personally I still sort of like it.  Pick the best method for your development style and keep on coding.