“Don’t ever leave your baby in the road.” – My First Computer Science Professor, 2015.

That came out of left field, didn’t it? However, the quote (much like YAGNI) makes a lot of sense in the world of Computer Science. Specifically, this quote refers to the idea that you should never “assume that you’ll always be careful and pay attention”, but rather you should prevent any mishaps from happening in the first place. Global variables, for the most part, should be avoided; the ability to be accessible from anywhere within the program is dangerous to say the least.

However, the “Singleton” method of refactoring seems to make an argument for the usage of global variables (provided that they still have a level of protection from modifying the data). Singleton refactoring works on the idea that having one “global” instance of a behavior class can save on memory; client classes using the same behavior can reference that single class. However, due to certain features (for example, making the constructor a private method within the class), having a global Singleton object will not endure the same problems that traditional global variables bring to the table.

This is opposed to the “Strategy” method, which involves creating new classes upon new classes for each new behavior found within a project. This way, we can create an interface for this behavior, and have it implemented by client classes that use it (this will save on memory from unused, inherited methods). Yes, the Strategy method is a step-up from mere method overriding. However, its need to constantly create new classes takes up massive mountains of memory in its own right (which can lead to poor performance).

Both ideas (the Singleton and the Strategy) are discussed within the articles linked below. I personally picked these articles due to the fact that they were my “help reference” when working on some of the homework assignments. Refactoring Guru is a great website that summarizes different refactoring strategies, as well as providing pseudocode and applications of each strategy in the real world.

I hope to use this newfound knowledge to improve upon my refactoring skills; this in turn will cut down on code smells, and create more efficient solutions to programming problems. When considering the Singleton design, we can use global variables without running into code smells such as “needless complexity” (by bringing in an unnecessary aspect), “viscosity” (by making future updates more difficult to implement), or “fragility” (by errors caused from having the data modified anywhere within the program). As for the Strategy design, we can ensure that classes only contain methods that they’ll actually use; this cuts down on the “needless repetition” coding smell (by ensuring that inherited methods don’t go unused).

Links: https://refactoring.guru/design-patterns/strategy

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

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

The year was 2005. I was a young child in elementary school, and eventually I was exposed to a little-known strategy game known as Warcraft III. As I championed the human race in my epic quest against the Undead Scourge of Lordaeron, I came across a sorceress ability known as “Polymorphism”. This powerful spell allowed its caster to turn an individual target into a harmless sheep. While entertaining and useful to say the least, little did I know that Polymorphism itself would take on a new form in the years to come…

Fast forward to 2021. I am being exposed once again to Polymorphism, this time as an essential feature of Object-Oriented programming. This would mark the third time that I am working with this concept (the other times being 2016-2017, and 2019 respectively). Polymorphism, in theory, isn’t very difficult: we take one idea (such as a function/method), and give it “many forms” (hence the name) among its various classes that use the function/method.

Listed below is an article about polymorphism from GeeksForGeeks, one of my “personal go-tos” when it comes to learning about programming practices. Specifically, “runtime polymorphism” will be more applicable in my software design class, due to its usage of method overriding. When using the “Strategy Design” of refactoring, we will create various interfaces and have them implemented using respective classes; these classes will then create their own version of the method.

Strategy design refactoring seems to provide an edge over “simple inheritance”, which would involve having a single base class (that all subclasses inherit off of). This “edge” is the removal of inherited methods that serve no purpose in certain subclasses; when the interface is implemented by the class, we can choose exactly what we want and don’t want from polymorphism.

However, having too many interfaces, or not enough data within the interface can cause its own problems. In addition, an interface is just that: a “top-down” view, with nothing beneath it; the methods need to be designed by the class using it. Meanwhile, inheritance may have redundant data, but at least you get all that and a bag of chips. In other words, inheritance provides one portion of functioning methods, plus whatever else is added on in the subclass.

I hope that I can use the idea of polymorphism, alongside interfaces, to reduce the amount of redundancy and complexity in my programs. There is no need to turn a program into a headache with unnecessary amounts of inheritance. In addition, part of this unnecessary material could be redundant – brought along for the ride, but not used during run-time.

Link: https://www.geeksforgeeks.org/polymorphism-in-java/

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Ever since the beginning of my programming career, I have had a plethora of professors provide several sayings that were helpful to becoming a better software engineer. One particular saying was acquired only a few weeks ago, during my Software Construction course. The saying goes: “YAGNI”, or when extended beyond the acronym: “(Y)ou (A)in’t (G)onna (N)eed (I)t”.

YAGNI is a useful term when considering one particular coding smell: Needless Complexity. Novice programmers often believe that they need to somehow squish every keyword, conditional statement and data structure into one massive, impressively diverse program. Yes, it is definitely useful to be knowledgeable in all of these areas. However, an advanced understanding of programming requires that one not only knows the skills, but also when to use them.

The article listed below (created by legendary software engineer Martin Fowler) explains the various reasons why YAGNI is so important. Specifically, it explains different kinds of “costs” related with unnecessary complexity: Costs of building, repairing, delaying and carrying the software. Considering these costs is such a crucial factor due to the fact that software should be designed to be cheap for the producer, yet effective and “easy-to-use” for the customer.

Understanding YAGNI, and its effectiveness against needless complexity, is invaluable to achieving proficiency in software design. The class does not want us to build products “per se”; rather, it already expects that we can build the block from the get-go. Instead, this class focuses on “whittling away” at the back-end block to create something more beautiful and beneficial.

If anything, based on the material that Martin Fowler has presented to us, we need to take a look at our code and ask ourselves: “is this really necessary?” Do we really need this exception case if the chances of achieving the error make the lottery look like a safe bet? Are these security features needed when a simple password check can cut the mustard? Cutting down on needless complexity is a rather easy smell to work on, since the problem is based on our ability to work harder than we really need to. Instead of remembering every last line of code, we should remember the abstract ideas, and learn how to translate/implement them.

In conclusion, I believe that “YAGNI” is an essential saying that every programmer should know by heart. In addition, I strongly believe that the sooner a junior programmer can learn this rule, the better off they’ll be in the world of software design. The best way to avoid certain coding smells (such as viscosity) and technical debt is to instill proficient programming practices that avoid these problems to begin with.

Link: https://www.martinfowler.com/bliki/Yagni.html

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Greetings fellow programmers. Tonight I am pleased to write a rather useful blog, and one that has been “whipped up fresh” (meaning that I wrote the post rather quickly, and in one take). Anyways, onto the material!

As seen in class, it seems as though many of us (especially those who use Windows OS computers) have had trouble installing the “Docker” container program used for our homework. While I cannot guarantee this to be a “foolproof guide” that completely saves the day, hopefully it will provide some pointers and lead those who still struggle with its installation in the right direction.

Helpful hints for installing Docker (on Windows) include:

1. Enabling “Virtualization” on your task manager “CPU”. It is usually enabled by default, but can be enabled (if disabled) at the BIOS settings screen.
2. Installing Windows 10 Pro, Education, or some variant other than “Home”. Windows 10 Home will not work (for some reason). Windows 10 Education can be acquired for free from the WSU IT website with verification of a student ID.
3. Enabling features such as “Hyper-V”. This task gets a bit more complicated; it involves going to the control panel.

So, why did I post these tips, and especially so late after nearly everyone has already set up the software? To start, I don’t believe that everyone has the software set up, and even those who do may still experience some issues (such as myself). These tips, by the way, were derived from an article linked below (“How to Install Docker on Windows 10” by Harshal Bondre); said article can also be referenced in YouTube videos, class instructions, and other resources.

Personally, I chose this article for two reasons. First, I enjoy helping people, as mentioned in my introduction. I don’t want to see people having to go through the same struggles that I did when learning this material; nothing makes me happier than seeing someone else solve in 5 minutes a problem that took me 5 hours. Second, I firmly believe that maximum proficiency of a material is achieved when someone has the ability to teach it to someone else. If I am able to instruct others on how to install Docker, then it means that I know it by heart. I don’t just know the material so well that I answer questions right, I know it so well that I cannot answer them wrong.

As a student that enjoys helping others (and is aspiring to be a tutor, TA, or other form of future faculty), I may consider using the materials learned here to create a guide to setting up Docker. Alongside some colleagues, we can ensure that the Fall of 2021 will be the last time that any student has this much trouble installing essential class software.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Believe it or not, I have been coding since the year 2015. As the title implies, the first university that I attended (right out of high school) was the University of Massachusetts – Lowell. Interestingly enough, within my very first textbook at UML, I would be exposed to another kind of “UML” – Unified Modeling Language. At this time, Unified Modeling Language was little more than a reference at the back of the book; there was more written on the subject, but my mind was concentrating on concepts such as how to “calloc()” in C.

Fast forward 5 years, and now Unified Modeling Language takes on a larger role; it is being used for visual representations of classes and inheritance in Java code. This can be seen with the following YouTube video, “How To Make Easy UML Sequence Diagrams and Flow Charts with PlantUML” by user “Be A Better Dev”. Essentially, the video shows how Java code can be written and then turned into a UML chart for a visual representation of classes and their features.

Personally, I selected this particular video due to the fact that I enjoy using YouTube more than any other social media; this way, I can use the app for educational purposes as well as recreational ones. This nine minute video is a great way to learn about how to code for UML in a format that is digestible on a busy schedule (when at work, for example). In addition, I expect the material to be applicable to aspects of the course (such as homework and exams) due to it being another form of practice. Practice, practice and yet more practice is the most important way to retain any type of coding/programming knowledge, and UML is no different.

It’s crazy to think that something barely glossed over from my educational journey five years ago would be so prevalent in the present day. However, it makes sense; programming practices such as using an arrow (->) operator or parentheses for a method are given new meanings when working with UML. Extending this further, programming syntax can create additional effects within the PlantUML environment. For example, placing an arrow on one side or another of an entity will effect exactly where it extends from on said entity.

As a final note, I am glad that I am able to work with this newfound technology. Ever since my days at UML, I have been wondering about when my code would leave the IDE environment and tackle more “lively” features (such as a graphical interface). Thanks to Unified Modeling Language, I now have a method of making my code come to life.

Article Link: https://www.youtube.com/watch?v=xObBUVDMbQs

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.