Through the duration of this class, we have worked a lot with different types of classes, abstract and concrete, as well as interfaces to better design the code. It was not a new concept to me, as I have learned some of the basics to these in prior classes. However, I never truly understood the benefits and the right time to incorporate each. The articles I found give a simple explanation on the distinctions between concrete classes, abstract classes, and interfaces, as well as the correct situations to use them in.

A concrete class, sometimes just referred to as a class, is used to specify any entity. It also can work as a blueprint for all entities with the same attributes. An abstract class and interfaces are similar and was often confusing for me to distinguish the two of them at first. An abstract class will have methods implemented inside the body, but abstract methods will not have the body of the method inside this class. For example, the duck class I was working with for Homework 2 has the abstract class Duck and the abstract method display(). The body of the method is not present in the abstract class because the different concrete classes implementing Duck uses display() to show different messages. An interface only has the method names included for classes to implement with the interface but does not have any body of the methods. This is what partially distinguishes abstract classes from interfaces, as abstract classes can have concrete methods defined in them while interfaces can only have the method names defined. Interfaces are handy when only needing to enforce a contract. Whoever implements this interface will provide an implementation of all the methods. Abstract classes are helpful when only needing partial implementation, which leaves the responsibility of implementing non-useful methods from the class.

The phrase “program to an interface, not an implementation” is new to me and I am starting to make more sense of it. Concrete classes are the actual implementation, interfaces are the contract, and abstract classes are a trade-off between both. Being able to fully program these three structures into the program helps with maintainability, extensibility, and testability. When programming to an interface, you are forced to split the program into subsystems, with each subsystem responsible for certain tasks and having the ability to communicate with each other to complete the whole task. The key to making the program more flexible is focusing the design on what the code is doing rather than how it does it.

I decided to pick this topic for my blog because I had always had a good idea of how to physically write programs to function correctly. However, something that I never focused on before was the structure of the code which can help when needing to develop the program further after initial creation. Most of our time spent in the class so far has been focusing on this concept and it is proving to be very important the more a program continues to develop.

Program to Interface, Not Implementation – Beginner’s Tutorial for Understanding Interface, Abstract Class and Concrete Class – CodeProject

Programming to an Interface – DZone

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

In the exciting realm of web development, the successful implementation of web systems hinges on understanding the intricate dance between three core components: the front end, the back end, and the data persistence layer. This blog post aims to dissect these vital components, shedding light on how they collaborate harmoniously to bring web applications to life.

The Front-End Canvas

Imagine the front end as the artist’s canvas, the visual facade of your web application that users interact with directly. It encompasses everything you see and interact with on a website—buttons, forms, navigation menus, and the overall layout. The front end relies on a trio of essential technologies:

1. HTML (Hypertext Markup Language): HTML acts as the foundation, structuring web pages by defining content and layout.
2. CSS (Cascading Style Sheets): CSS is the stylistic wizard responsible for the visual appeal, ensuring that the web elements harmonize seamlessly.
3. JavaScript: JavaScript adds interactivity to the canvas, bringing it to life by creating dynamic elements, managing user input, and facilitating communication with the back end.

The Back-End Engine

Behind the scenes, the back end serves as the powerhouse of your web application. It handles user requests, processes data, interacts with databases, and sends responses. Several technologies and frameworks excel in back-end development:

1. Node.js: Node.js enables JavaScript to run on the server side, making full-stack development a breeze.
2. Ruby on Rails: Rails offers a structured framework that simplifies the creation of robust web applications with concise code.

The Data Persistence Layer

No web system is complete without a reliable data persistence layer. This layer manages data storage, retrieval, and efficient data management. It’s home to various types of databases, including:

1. MySQL: MySQL, a popular relational database, is known for its reliability and is widely used in web applications.

The Synchronized Symphony

These three layers—front end, back end, and data persistence—complement each other to deliver a seamless user experience. When a user interacts with the front end, JavaScript often sends HTTP requests to the back end. The back end processes these requests, interacts with the chosen database to retrieve or store data, and then sends a response back to the front end. JavaScript on the front end dynamically updates the user interface based on this response, creating a responsive and interactive web application.

In Closing

Understanding the synergy between the front end, back end, and data persistence layer is fundamental to web development. These layers work in harmony, much like the instruments in an orchestra, to create the symphony of a fully functional web system. As you embark on your web development journey, remember that mastery of these layers takes time, practice, and a touch of artistry. So, keep coding, keep building, and explore the boundless possibilities of web system implementation.

References:

• MDN Web Docs – HTML, CSS, and JavaScript
• MySQL Documentation

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

In the vast landscape of software development, there’s an underlying principle that seasoned developers know all too well: code should not only work but should also be maintainable, readable, and scalable. To achieve this, we often find ourselves identifying and addressing something known as “code smells” and their close cousins, “design smells.”

Understanding the Essence

Let’s start with the basics. Code smells are those subtle hints in your codebase that something might be off. They’re like those faint odors in your room that you can’t quite pinpoint but know need attention. These “smells” indicate potential issues that can make your code harder to understand, modify, and extend (Fowler, 1999).

On the other hand, design smells are more like the underlying structural issues in your code that lead to code smells. If code smells are the symptoms, design smells are the root causes (Beck et al., 2002). Identifying and addressing design smells is essential for maintaining a clean and healthy codebase.

Common Code Smells

1. Long Methods: Code smells often start with overly long methods or functions. When a function becomes a novel, it’s difficult to follow, debug, or modify. Break down long methods into smaller, focused ones for clarity (Fowler, 1999).
2. Duplicate Code: Repeating the same code in multiple places is a classic smell. It leads to maintenance nightmares since you have to make changes in multiple locations when updates are needed (Fowler, 1999).
3. Large Classes: Just as long methods can be problematic, large classes or modules can become unwieldy. Split them into smaller, more cohesive units (Fowler, 1999).
4. Magic Numbers: Using hard-coded numbers without context is a recipe for confusion. Replace them with named constants or variables (Fowler, 1999).

The Path to Design Smells

Design smells often stem from issues in the overall architecture and structure of your code. Some common design smells include:

1. God Class: When one class knows too much and does too much, it becomes a “God Class.” This violates the Single Responsibility Principle (SRP) and makes the code less modular (Fowler, 1999).
2. Spaghetti Code: Unstructured and tangled code that’s hard to follow is like a bowl of spaghetti. It usually arises from poor planning and lack of separation of concerns (Kerievsky, 2014).
3. Circular Dependencies: When modules or classes depend on each other in a circular manner, it can lead to maintenance challenges and hinder code reusability (Fowler, 1999).

The Importance of Addressing Smells

Ignoring code and design smells is like letting that mysterious odor in your room linger; it won’t get better on its own. Instead, it can worsen over time and create a bigger mess to clean up (Fowler, 1999).

Addressing code smells and design smells early in the development process can save time, reduce bugs, and make your codebase more maintainable. It’s like opening the window to let fresh air in; your code will become more pleasant to work with (Fowler, 1999).

Conclusion

In the world of software development, understanding and recognizing code smells and design smells is essential for writing clean, maintainable, and efficient code (Fowler, 1999). Just as identifying that peculiar odor in your room can lead to a more comfortable living space, addressing these smells in your code can lead to a more productive and enjoyable development experience.

So, as you embark on your coding journey, keep your nose keen, and don’t hesitate to refactor and improve your code whenever you detect those telltale aromas of code and design smells. Your future self—and your fellow developers—will thank you.

References:

1. Fowler, M. (1999). Refactoring: Improving the Design of Existing Code.
2. Beck, K., et al. (2002). Extreme Programming Explained: Embrace Change.
3. Kerievsky, J. (2014). Refactoring to Patterns.

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu 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.

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.