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.

For the entirety of this course so far we have been working and getting familiar with the version control tool git. In this week’s blog I will be writing about a blog called “What is Git | Explore a Distributed Version Control Tool” by Reshma Ahmed. I have chosen this article in particular to see how it came to existence, the roles they play in companies, and to get a further understanding in addition to what we have learned in class.

From the article I have learned the different types of version control such as centralized version control system and distributed version control systems. Git was created in 2005 by Linus Torvalds designed to “handle small to large projects with efficiency”. Git is a distributive version control system which is a system that prevents corruption and crashes that were caused from having a server hosted in a single repository such as in centralized version control systems due to everyone having a copy on their machine of their local repository. When reflecting back to the course we have been practicing with pushing and pulling from repositories, branches, as well as removing and adding commits. The GitKit activities worked on in class shown us practical issues that one may face with git such as merging issues as well as issues involving different versions of commits.

The article describes some of the features of git which we have looked at in class such as being open source as well as being secure. Open source software encourages transparency, collaboration, and accessibility similar to the FOSS communities mentioned in the first GitKit activity done in class. The article reads “Git uses the SHA1 to name and identify objects within its repository”. This concept becomes apparent from seeing in the GitKit activities done in class when applying commands such as “git log” that shows a commits’ hash as well as the date a commit was made.

Git not only is used in the software development community but plays a detrimental role in companies with more and more companies using git as their go-to version control system. Some of these companies include tech giants such as “Facebook, Yahoo, Twitter, eBay, Salesforce, [and] Microsoft” which shows the significance of git.

When reflecting for my personal future use of git, practical applications of git in the field of machine learning and data science is using git to manage datasets to ensure reproducibility as well as data integrity. In addition, I plan on using git for my data mining course project when collaborating with other peers.

Links

https://www.edureka.co/blog/what-is-git/#companies_using_git

From the blog CS@Worcester – Anthony Duong CS Blog by anthony duong and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Kyler's Blog by kylerlai 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.

Being able to build a set of skills that could be one day used by a team of craftsmen is crucial when walking into any profession. Although it’s a little hard for anyone to go into a job that requires one to know a set of skills. It should be clear-cut on the application. But I do agree on attempting to get assimilated on those skills whenever possible because in some cases, these employers want to be able to rely on the fact that you won’t be a liability to the workflow. This goes for a lot of jobs once again. I used to work a construction job when I was 17-18 years old, it was when I wasn’t so sure if I wanted to pursue a career in software craftmanship and I already had a lot of knowledge in the construction trade, four years of knowledge to be exact. The man who acts as a “master” figure to me told me that competence is everything in the professional world, and having little competence is better than having no competence.

It’s also important to expand the competence because it could expand one’s reputation of being a good craftsman for other employers to look at. I would also like to add that being able to work on the skills that one might lack is also important to expand one’s value to the team. Interviewers or hiring managers want to be able to understand your worth in a company, being able to list off certain tasks that can be done to an issue is invaluable, and being able to apply the knowledge that one has is more important. From experience, it also helps to have an experience that proves that you have the concrete skill, no days it’s not enough for employers to see that you know a certificate or course that you might have taken.

It’s more important for the employer to recognize that you have applied the skill set to other, similar jobs or projects. This pattern is a very general one that will be brought up countless times in apprentice’s come-up but, non the less it’s a very important pattern that can be applied to more than just software craftsmanship.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.