This week I wanted to write a post about the last SOLID design principle, Dependency Inversion. This principle deals with the relationship between interfaces that operate at a high system level and low system level interfaces.

Composed of two parts, the Dependency Inversion Principle as stated by Robert C. Martin is:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
2. Abstractions should not depend on details. Details should depend on abstractions.

While the name “Dependency Inversion” might imply inverting the dependency relationship between modules, applying this principle actually involves building both high-level and low-level modules from the same abstraction. Constructing your code to abide by the previous SOLID principles, particularly the Open/Closed Principle and the Liskov Substitution Principle, should implicitly also result in code that abides by the Dependency Inversion Principle. The Open/Closed Principle states that a software module should be open for extension, but closed for modification, and the Liskov Substitution Principle states that an interface should be able to be replaced by a separate implementation of the same parent interface without compromising the functioning of the software.

The author includes another coffee machine themed example, detailing how to apply the SOLID design principles to two separate classes of coffee machine. Starting with two classes, BasicCoffeeMachine and PremiumCoffeeMachine. The classes are very similar, with the only differences being an extra class variable representing a coffee bean grinder and a method to brew espresso for the PremiumCoffeeMachine class. The author describes their process for defining suitable abstractions for a piece of software representing coffee machines, including their decision to have the methods for brewing filter coffee and espresso split into two interfaces. A potential coffee machine class representing a machine with the capability to brew either filter or ground coffee can easily be built by implementing both of these interfaces and overriding the methods within the concrete classes.

Refactoring the code this way enables independence between interfaces and implementations and makes expanding on the code base easier and safer. With fewer dependencies between modules, the effects of any changes to existing code won’t ripple out to other parts of your software.

I wanted to review this principle specifically because I wanted to refactor the interfaces from some old projects of mine. I wrote some Java classes meant to represent characters in a fantasy role-playing game, complete with character levels and statistics. As I left it though, the code is only capable of creating characters meant for the user, and not any non-playable characters or any other sort of entities. I want to go back and redesign my code so that I have fewer methods that only function with specific classes, and more functionality to create and edit characters. I remember I had a lot of trouble trying to increment a character’s level by 1 and increasing their stats accordingly, and I get the feeling that refactoring my code with the SOLID principles in mind will help me get it to a place I am happier with.

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.

This week, I wanted to continue writing about the SOLID software design principles. We’ve reached the letter “I”, which represents the Interface Segregation Principle. I’ve been noticing a theme across the SOLID design principles that as many parts of your software as you can manage should be independent of one another, so that modifications can be made to a part without compromising the whole. The Interface Segregation Principle brings the relationship between the software user and designer into focus.

Once again defined by Robert C. Martin, the Interface Segregation Principle is “Clients should not be forced to depend upon interfaces that they do not use.” This principle goes hand-in-hand with the previously defined Single Responsibility Principle, which declares that “A class should have one, and only one, reason to change.” The goal of abiding by these principles is to produce code that is resilient to future modifications and fostering that resilience by building independent software components.

The article provides the real-life example of a years-old piece of software being iterated on. The designers may want to add new methods to existing interfaces, even though that may introduce new dependencies to the interface and violate the Single Responsibility Principle. The author introduces the term “interface pollution”, referring to the phenomenon of existing interfaces becoming cluttered with new methods that introduce new responsibilities to the interface, rather than building new interfaces that handle those responsibilities.

The author provides a practical example of this principle through another Coffee Machine implementation. A new EspressoMachine class is proposed but requires a new method that the BasicCoffeeMachine interface doesn’t include. The problem of interface pollution is illustrated simply in this example, when a brewEspresso() method is added to the CoffeeMachine interface to support the new EspressoMachine class. No other kinds of CoffeeMachine would use this method. This approach also introduces the issue that BasicCoffeeMachine could try calling brewEspresso(), or EspressoMachine could try calling brewFilterCoffee(), and either case would throw an exception.

The solution in this case is to create new interfaces from the existing CoffeeMachine interface, FilterCoffeeMachine and EspressoCoffeeMachine. This way, only the methods required by either type of concrete CoffeeMachine class can be accessed. This approach strengthens the independence of the concrete classes. If a new CoffeeMachine design demands methods from both interfaces, it can simply implement from both.

I chose to write about this topic because I’m still learning how to assign responsibilities to different parts of my software. Having interfaces that contain too many methods rather than continuing to further specialize them is an issue I’ve faced in software that I’ve written myself. Studying the SOLID principles and actively applying them to my work will help save me a lot of time and effort in my future projects.

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.

This week, I wanted to continue writing about the SOLID software design principles. The next principle I have to cover is the Liskov substitution principle. This principle expands upon the Open/Closed principle I wrote about the previous week, providing a guideline on how a superclass and its child classes should behave.

This principle was first defined by Barbara Liskov in 1987, and later adopted by Robert C. Martin. From a paper that Barbara Liskov cowrote with Jeanette Wing, they defined the Liskov substitution principle as a mathematical property: “Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.”

Translated into plain English, this principle states that instances of a superclass in a program should be able to be replaced by one of its subclasses without breaking the program. Overridden methods from a subclass must accept the same input as the superclass’s original method, and the return value of a subclass’s method must be able to be used the same way as the value returned by a superclass’s original method.

Creating code that abides by this principle isn’t simple, as the compiler can only verify that the structure of your code is correct, not that any specific behavior of your code always executes when desired. Creating robust test classes and cases is the best way to check if your code is following the Liskov substitution principle, checking portions of your program using all subclasses of a particular component to ensure there are no resulting errors or loss in performance.

The author of this article series has included another code example representing a coffee machine to illustrate this design principle, as they have done in their previous articles. They present the problem of creating different subclasses of coffee machines from a generic parent class, with two classes with an “addCoffee()” method that accepts two different types of objects, CoffeeBean and GroundCoffee. The author suggests two solutions, either creating a common Coffee class that can be utilized by both the BasicCoffeeMachine class and the PremiumCoffeeMachine class, or create a common implementation of a “brewCoffee()” method that also appears in both CoffeeMachine classes. The first solution would violate the Liskov substitution principle, because each CoffeeMachine class would need to validate that they are receiving the correct input type for the addCoffee() method, as the BasicCoffeeMachine class can only use the GroundCoffee type, and not the CoffeeBean type. The author’s preferred solution is to remove the addCoffee() method from both CoffeeMachine classes and implement a common brewCoffee() method in the CoffeeMachine interface implemented by BasicCoffeeMachine and PremiumCoffeeMachine. Since all CoffeeMachines are expected to brew filtered coffee grounds, this brewCoffee() method should have that responsibility.

I want to further understand this principle because in a past project, I made a simple video game that used lots of objects of different subtypes that inherited from a single GameObject parent class. If I want to return to that project, or begin a similar one in the future, I want to make sure that I am not losing any functionality as I design and implement subclasses of a broader parent class.

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.

This week, I wanted to continue from my previous entry describing the Single Responsibility Principle. The next concept named in the SOLID design philosophies is the Open-Closed Principle. I first heard the name of this design philosophy in one of my computer science courses. I couldn’t figure out what exactly it meant just going intuitively from the name, however, so I returned to the Stackify website from my previous blog post to continue reading about the SOLID principles.

The Open-Closed Principle was first coined by Bertrand Meyer in his 1988 book “Object-Oriented Software Construction”. Robert C. Martin would later adopt the Open-Closed Principle, calling it “the most important principle of object-oriented design”. He would explain the Open-Closed Principle as “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” In practice, this means programming such that new functionalities may be added without changing the existing code.

Bertrand Meyer originally proposed inheritance as a means of abiding by the Open-Closed design principle, but this introduces the problem of tight coupling between software classes. If one class is too dependent on a parent class to function, it will be difficult to make changes to one class without modifying the other class to maintain functionality. Instead, Robert C. Martin suggests using interfaces rather than concrete superclasses, redefining this design philosophy as the Polymorphic Open/Closed principle. The abstraction provided by interfaces helps avoid the problem of tight coupling between software classes.

The article goes on to provide a practical example of the application of the Open/Closed principle through creating a software class representing a coffee machine, and an accompanying class representing a simple app that controls the coffee machine. The article presents the situation where the user may have a different kind of coffee machine that they would like to control with the same software app. The process of refactoring the BasicCoffeeMachine code to implement a broader CoffeeMachine interface is detailed, as well as the process of refactoring the CoffeeApp to utilize the new CoffeeMachine interface. This way, the functionality of our software was greatly expanded, without having to remove large portions of our previously written code.

I chose to research more about the Open/Closed Principle this week because I don’t find myself using interfaces in my projects as often as I should. I could save space and make my code more efficient if I took care to design my software classes to an interface. The example in the article seems like it is employing the Strategy method when instantiating the CoffeeMachine objects. Understanding both the Strategy method and the Open/Closed principle will help me to make better use of interfaces when designing software classes in the future.

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.

This week, I wanted to further research software design principles and guidelines. In my past coding projects, there wasn’t any set framework or model I would stick to when writing my code. This led to creating classes that depended on each other too closely, and methods that attempted to accomplish too many tasks at once. To create better functioning software, I’m going to need to learn the best design practices to abide by at the outset of the project.

A popular set of design principles among software professionals are the SOLID design principles. Named by Robert C. Martin, SOLID is an acronym for 5 design principles that lend themselves to efficient, functional software. These 5 principles are:

1. Single Responsibility Principle
2. Open / Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion

This blog post from the Stackify website focuses on the Single Responsibility Principle and its role in the software development process. Robert C. Martin describes the Single Responsibility Principle as “A class should have one, and only one, reason to change.” Abiding by this principle may help avoid unintended consequences from future updates to the software, as fewer interactions may break as a result of changes to the code.

Even small-scale software projects will likely change significantly over time, and keeping the Single Responsibility Principle in mind will prevent your classes from being encumbered by unnecessary dependencies on each other. If a single class is called upon by many other classes within your software, changes to that class may break the functionality of any classes dependent on that parent class.

Making an effort to keep components of your program independent of one another also has the benefit of keeping your project simple for a human to understand and explain. When a piece of software can be understood by the developer or team of developers working on it, the flow of productivity is so much greater since fewer effort is being spent on deciphering how the software functions. Updates and new features can also be released more quickly and consistently when the structure of the program is easier to modify without compromising the interactions between its components.

Abiding by the Single Responsibility Principle does not mean only creating classes with a singular function, however. This approach can lead to the same problem of too many classes becoming dependent on a singular parent class, and unnecessarily complicates the structure of your program.

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.

https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith

Since learning about different software architecture styles like the monolithic architecture, the client-server architecture and the microservices architecture, I’ve been curious how large-scale applications transition from one architecture to another as the project grows in scale. I found this blog post on the Atlassian website breaking down the differences between the monolithic architecture and the microservices architecture, as well as telling the story of Netflix’s innovative migration from a monolithic architecture to a microservices architecture.

The article begins with the example of Netflix’s transition between architectures. Netflix was growing rapidly by 2009 and needed to expand its software infrastructure to meet the massive demand. Before “microservices” as a term was in wide usage, Netflix was one of the first major companies to migrate to a microservices architecture, and in 2015 earned a JAX Special Jury award for its successful deployment. Netflix’s new architecture would model itself on DevOps, defined by Amazon as “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity (https://aws.amazon.com/devops/what-is-devops/#:~:text=DevOps%20is%20the%20combination%20of,development%20and%20infrastructure%20management%20processes.)”.

Following the story of Netflix’s change in infrastructure model, the article continues with an explanation of the monolithic architecture style. The monolithic architecture is a traditional design, which is defined by the application being housed in a single self-contained server. This architecture is simple to understand and easy to use as a foundation for your application. The major drawback of the monolith, however, is the difficulty in updating the application. Making changes to the code base requires bringing the entire service offline. Monolith architectures are not scalable with the growth of the application either.

The microservices architecture addresses some of the disadvantages that come along with a monolith architecture. The application is divided into independent services each with their own databases and methods. With this architecture model, only the components of the application that require changes need to be taken down, leaving the other components of the application free to continue working.

One inherent barrier to using the microservices architecture is the expense of multiple machines to host the different microservices, as well as storage space for their accompanying databases. It may only be beneficial for an application to transition to a microservices model once it has reached a certain scale. Small to mid-size applications may be perfectly well served by monolith architectures for much less cost than hosting the application across a microservices architecture.

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.

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.

This week, I wanted to make a post showcasing some examples of documentation for free, open source software. Comprehensive documentation is essential for any software project, so I want to see what useful documentation looks like. I was inspired to make this post when I found myself in need of a new podcast app for my Android device. The one I had been using was no longer refreshing my subscribed podcasts when I opened the app, and I wasn’t able to load the episode lists of any shows. I needed a new podcast app, but I didn’t immediately want to download the Google Podcasts app that was at the top of the search results on their Play Store. I understand Google collects user telemetry and data from their apps, and I didn’t want Google to connect advertising data to my account from the ads many podcasts read from their sponsors. Ideally, I wanted a free and open source app I could use so I could feel more secure in my data privacy.

From Opensource.com, the definition of open source software is “software with source code that anyone can inspect, modify, and enhance.” Many open source projects are supported by communities of volunteers connected over the Internet. The benefits of open source software include stability over time, meaning that because the project can be maintained indefinitely by anyone, the software may remain compatible with modern systems for a longer time than closed source software. Open source software also promotes security for end users. Since the software’s source code is openly accessible, there is a greater chance that undesirable code is deleted or corrected once discovered.

Large-scale projects that require collaboration are supported by extensive documentation for end users. The example I mentioned earlier, AntennaPod, has a simple-to-navigate documentation page that begins with the basic act of subscribing to a podcast, and ends with instructions for podcast creators on how to have their podcast listed on the app through the use of existing podcast dictionaries. One interesting section I found was an explanation of centralized versus distributed podcast apps. Centralized apps are always in communication with a central server, and content is delivered from that server to your device. In contrast, distributed apps send requests to the podcast publishers directly, and do not contact a central server. This approach allows the developers of the app to devote more resources to maintaining and iterating on the app, instead of maintaining a server. Distributed apps are also a protection for user privacy, as there is no interaction with any central server to provide an opportunity to collect user data. The app developers don’t have access to information like which users are subscribed to which shows either. This decentralized, distributed approach also helps protect against censorship, because there are multiple sources to download shows from instead of one central server owned by one entity. Likewise, the app will continue to function even if development ceases, where in contrast a central app will stop functioning if the central server shuts down.

Sources:

• https://opensource.com/resources/what-open-source
• https://antennapod.org/documentation/

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.