https://refactoring.guru/design-patterns/singleton

This week, I wanted to a find a source relating to software design and architectures. I’ve been curious about what I would need to know so I could write more robust and efficient code. One aspect of improving my code would be knowing how best to preserve available system memory and perform whatever tasks I need to within as few CPU cycles as I can. If my program is creating multiple instances of a class that are all doing the same thing, my code would be consuming more system resources than if I had one instance of a class that could be accessed by other parts of my code. The Singleton design pattern seeks to preserve memory consumption by utilizing a single static instance of a class that may be globally referenced from the rest of the program. To properly implement the Singleton, the constructor for your Singleton instance should be static and private. To get the instance, you would also need a public static creation method.

My homework for this week involves refactoring a class into the Singleton pattern, so I was especially interested in learning about it. I found this blog called The Refactoring Guru, and a post explaining the implementation of the Singleton, as well as the pros and cons from a design perspective. The Singleton design is useful when a program needs global access to a class, like when a program has a single attached database. The drawbacks of the Singleton approach, though, are that it does too many things at once in violation of the Single Responsibility Principle, and that it may compromise your program’s security because of a crucial class being accessed as a global variable.

The final paragraph of the blog post makes some comparisons between the Singleton design and two other software design patterns, Façade and Flyweight. Façade is a design pattern of constructing a simple user interface with a complicated backend. This design pattern offers a sort of “black box” functionality to users, having a simple frontend to interact with without the need to inform users about the inner implementations of the software. The practical example given for a Façade software design is a video encoding service that accepts video files from the user as input and returns the same file encoded in a new file format. The user would only need to interact with the function that accepts a file and a desired file type as parameters, without needing to access the methods within the program that perform operations on the input file.

This blog includes helpful illustrations and pseudocode to explain multiple different software design patterns. I’ve been needing more resources on broader software structure and design rather than individual blocks of code, and I’m happy that I found this website.

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

When it comes to writing code, the one thing you want to keep an eye on is that you’re not using the same line of code you used on multiple projects. The don’t repeat yourself principle also known as the DRY principle aims to solve problems is knowledge of duplication. This idea is applied through all levels and phases of software development, most of the time it’s used while making classes. When making classes you end up implementing the same logic in multiple parts of the code. A solution is to remove the common functionality and only implement the parts that are different.

Another example of repeating yourself happens while you’re storing data. You start to create unnecessary attributes in your table, usually, you can derive those attributes from other attributes since they’re mutually dependent on each other. The problem with duplication is that things can change and once you make one change you have to change all of its representations. Making changes requires analysis, In other words not making any proper changes will lead to opposite representations of the same knowledge. These duplicates can happen in multiple ways someone could make a mistake while making the design, and a strict deadline can make people feel rushed to meet that deadline.

DRY is a principle and there are three methods to implement that principle. First is abstractions which are commonly used when making classes, when multiple classes are shared and come with common logic you simply want to abstract the logic into a superclass that each class inherits. The standard object-oriented program has a lot of practices that encourage the DRY principle for writing reusable, readable, and maintainable code. Second automation is a project case for developers. It’s to make sure that developers are communicating with each other so they don’t repeat finished work and talk about any problems they’re having. Last is normalization, this case is for designing databases. Repetition is common in a lot of data representation but creates redundant data, which is hard to maintain. You would want to extract the cases into a separate entity then the source references that entity. The goal is to ensure that the data is consistent and distributed correctly. Data normalization removes repetition in data, making the database more flexible. 

The reason why I picked this topic is because I tend to repeat myself a lot thinking that it wouldn’t be too much of a problem for me to end up having problems with my code and making my code a little more confusing. By using this principle and using the three methods it helps me make sure that my code is readable, reusable, and easy to maintain. I feel like this principle is important to use for everybody who is making a code by themselves or as a group.

Sources: https://www.plutora.com/blog/understanding-the-dry-dont-repeat-yourself-principle

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.