SOLID is an acronym that stands for the 5 different principles that help write high-quality, maintainable, and scalable code. These include Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP). Each provides their own benefits and work in tandem together when designing a program.

SRP states that a class should only have one responsibility, meaning only one reason to change. This helps prevent a class from having too many responsibilities that can affect each other when one is changed. Following SRP ensures that the code will be easier to comprehend and prone to fewer errors. However, it is harder than it sounds to fulfill this principle. The quickest solution to adding a new method or functionality would be to add it to existing code, but this could lead to trouble down the road when trying to maintain the code.

OCP states that software classes, modules, functions, etc. should be open for extension but closed for modification. This is essential because it allows entities to be extended without modification so that developers can add new functionality without risking the chance of breaking the code. Adding an additional level of abstraction with the use of interfaces help design the program to provide loose coupling.

LSP states that any instance of a derived class should be substitutable for an instance of its base class without affecting the program in a harmful way. The importance of this principle revolves around the ability to ensure the behavior of the program remains consistent and predictable. Unfortunately, there is no easy way to enforce this principle, so the user must add their own test cases for the objects of each subclass to ensure that the code does not significantly change the functionality.

ISP focuses on designing interfaces that are specific to a user’s needs. Instead of creating a large interface that covers all methods, it is more beneficial to split up the methods across smaller, more focused interfaces that are less coupled. For example, having too many methods in an interface can sometimes cause issues in the code, so separating the methods into individual interfaces that can be implemented by a certain class.

DIP states that high-level modules should not depend on lower-level modules but should depend on abstractions. This approach aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend. An important thing to note is that both high-level and low-level modules depend on abstractions. Dependency Inversion utilizes the SOLID principles which in turn leads to a more refined and maintainable code.

This is related to the class subject in many ways because it works as a guideline to write the most convenient code for programmers to maintain. Testing the aforementioned code is a simpler process when abiding to the SOLID principles as well. It also allows for easy scalability, making it essential for large code sets that evolve and become more complex over time.

SOLID Design Principles: The Single Responsibility Explained (stackify.com)

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 dynamic realm of software development, a beacon of practical wisdom guides developers through the maze of endless possibilities: YAGNI, an acronym for “You Ain’t Gonna Need It.” This principle advocates a minimalist approach, urging developers to focus on the essential and resist the allure of unnecessary features that might never see the light of day.

YAGNI encourages a “just-in-time” mindset, directing development efforts exclusively toward existing requirements. The core idea is simple: avoid building features or solutions prematurely. Unnecessary additions can introduce complexity, extend development time, and potentially introduce bugs. By embracing YAGNI, developers keep a sharp focus on immediate goals, prevent over-engineering, and maintain a lean and efficient codebase. This not only enhances the development process but also simplifies debugging and ensures a clean and manageable codebase.

Why This Resource?

This extended version builds upon the insights of my previous blog, providing a deeper exploration of the YAGNI principle. The selected resources, Martin Fowler’s YAGNI and C2 Wiki’s YouArentGonnaNeedIt, stood out as foundational pieces providing deep insights into the YAGNI principle. Martin Fowler, a prominent figure in software development, and the collaborative wisdom of the C2 Wiki community added credibility to the understanding of YAGNI.

Insights and Personal Reflection

Delving into Martin Fowler’s exploration of YAGNI, I found a nuanced perspective on the principle. Fowler emphasized the importance of simplicity and addressed the misconception that YAGNI means avoiding all forms of future-proofing. It struck a chord with my experiences, providing a more refined view of when and how to apply YAGNI.

The C2 Wiki, on the other hand, offered a historical context and a communal understanding of YAGNI. Reading through the anecdotes and shared experiences of developers reinforced the practicality and effectiveness of the principle. It resonated with me on a personal level, as I could relate to the scenarios described by fellow developers.

Application in Future Practice

Armed with a deeper understanding from these resources, I anticipate applying the YAGNI principle judiciously in my future projects. Fowler’s insights clarified the delicate balance between avoiding premature features and wisely preparing for potential future needs. The collective wisdom from the C2 Wiki provided a broader perspective, showcasing the universality of the challenges YAGNI addresses.

Conclusion

This extended exploration, building upon the foundation laid in the previous blog, solidifies my grasp of the YAGNI principle. The combination of Martin Fowler’s authoritative voice and the collective wisdom of the C2 Wiki community has enriched my comprehension. I am confident that this refined understanding will significantly influence my coding practices, contributing to the creation of more efficient, maintainable, and adaptive software solutions.

You can read more about YAGNI at:

• YAGNI: You Aren’t Gonna Need It – Martin Fowler
• YouArentGonnaNeedIt – C2 Wiki

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.

Refactoring Code

Refactoring is an important process when maintaining code bases. The goal of refactoring is to change the implementation, definition, and/or the structure of the code without changing pre-existing functionality of the application. Refactoring allows for better extensibility, maintainability, and readability. Refactoring usually results in smaller and simpler code bases, allowing new functionality easier to implement.

When to refactor?

Because refactoring results in simpler code bases, refactoring should be done before adding new features. Working with clean code after refactoring makes the process of adding new functionality easier. For example, if the code base is not extensible, then adding new functionality might break the code leading to more work to fix the problem. Refactoring should also be done before code reviews or before addressing bugs.

What code needs refactoring?

Code smells can be defined as structures in the code that indicate violations of fundamental design principles and negatively impact design quality. Code smells can be used to identify what needs to be refactored. There are over 70 refactoring techniques that help identify problems and provide a known solution. Some techniques are the Extract Method, Replacing Temp with Query, and Encapsulation of a Field.

Refactoring techniques

Extract Method

The Extract Method can be used when code can be grouped together. For example, there is a class called ‘Student’ that has two print statements that prints student details such as name and year. Refactoring would include grouping the two print statements together into its own function. This is helpful because if you wanted to add more details to be printed, you only have to add one line to the function.

Replace Temp with Query

Temp refers to a temporary variable that holds a value of an expression to be used later in the code. This technique replaces the temp variable with a query method that returns the result of an expression. For example, there is a variable where ‘basePrice = quantity * costPerItem’. The variable can be represented as a new method called ‘basePrice()’ that returns the expression, ‘quantity * costPerItem’. If the temp variable is used among multiple classes, having a common method would more manageable.

Encapsulate Field

Encapsulating a field involves using methods that read and write data rather than accessing data directly. When accessing variables directly, they are often set to public which allows the data to be modified without a way to validate the change. Getter and Setter methods should be used to access class variables instead because the access level for the variables can be set to private, meaning the data itself cannot be accessed unless using the access methods. Using access methods provides a way to validate changes.

Reflection

This resource was used because it was clear and concise, making the content easy to understand. The article also included code examples of the techniques which improved comprehension. Before reading, I was unaware of some of the techniques listed which will be helpful when refactoring in the future.

Resources:

https://www.geeksforgeeks.org/refactoring-introduction-and-its-techniques/#

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

Rest API and CS-343 are a duo that just sounds right. When trying to give to come up with a blog idea for such a class, I couldn’t picture a clearer GIF than our dear friend Patrick Star

I try my best to not compare but it is hard not to when I compare my blog process to CS-348 and made the sudden realization I have over a hundred ideas for that class.

However, in the short two-minute comparison, I realized that since my class was approaching MS-Billion-Gillion-Trillion in Micrroservice Activity, it would be a great time to take a deep dive into Rest API.

A lot of the articles I had a chance to come across I noticed to have lots of gaps in the information provided. Noticed in some there was missing clarification, simplified introductions, and Chat-GPT “Whats Rest API” money makers. REST API and API in a Nutshell. Deep Diving Into REST API by Krunal Chauhan offered the best of both worlds in offering me a crash course on Rest API and a challenging question started on the advanced side of such a topic.

Crash Course KNOWS:

1. Definition of API:
   • API stands for Application Programming Interface.
   • It acts as a software intermediary allowing communication between different applications or devices.
2. Need for API:
   • Necessary for communication with various devices and services.
   • Enables interaction with web browsers, mobile devices, and third-party software.
3. API Explanation (Metaphor):
   • Describes API as a mediator, like a waiter in a restaurant, facilitating communication between the client (user) and the backend (kitchen).
4. How API Works:
   • APIs communicate through rules/protocols.
   • Typically works over the internet via HTTP, built on top of the TCP/IP protocol.
   • Analogizes API communication to a customer (user) placing an order through a waiter (API) to the kitchen (backend).
5. REST API:
   • Represents a style of API architecture that uses HTTP and is user-friendly.
   • Introduced by Roy Fielding and is considered a standard protocol for web APIs.
   • Works with HTTP methods like GET, PUT, POST, and DELETE.

CRASH CROUSE DEEP DIVE:

1. Building Blocks of API:
   • API Interface Block: Defines specifications for the API, often using HTTP.
   • API Controller Block: Manages traffic, and handles authentication, and authorization.
   • API Runtime Block: Executes the business logic of the API.
   • API Data Bridge Block: Facilitates seamless access to shared data storage.
2. API Management:
   • Involves designing, publishing, documenting, and analyzing APIs in a secure environment.
   • Components include API design, API gateway, API store/developer portal, and API analytics/dashboard.
3. Types of API:
   • Open APIs (Public API): No restrictions on access.
   • Partner APIs: Requires specific rights or licenses.
   • Internal APIs (Private APIs): Used within a company for internal purposes.
4. REST API Architecture Components:
   • REST Client: Code or app accessing REST services.
   • REST Server: Offers API and resources.
   • REST API: Defines endpoints and methods.
   • Endpoint/URI: Specifies where to find a resource.
   • REST Request: Includes HTTP method, endpoint, headers, and body.
   • REST Response: The server sends a representation of the resource, often in XML or JSON.

I enjoyed reading these types of articles when the reading flow is smooth and coherent to the subject. If you can believe it or even if you check the article yourself, the summary above is my notes for the article and about how 99% of the article flowed.

A good chunk of the reading was a good reminder of things I already learned but there was also a few sections that required me to go back as we have not had the chance to talk in-depth about them.

Specifically, the Rest API Management as this was the first time I ever heard these terms before and was not a section we were able to cover just yet. Out of the article I was able to break down the Rest API Management into 4 sections.

1. API Design:
   • This block enables users, including developers and partners, to design, publish, and deploy APIs. It includes recording documentation, security policies, descriptions, usage limits, runtime capabilities, and other relevant information.
2. API Gateway:
   • The API Gateway acts as a gatekeeper for all APIs. It handles tasks such as routing requests, composition, and protocol translation. It enforces relevant API security policies, ensures authorization, and guarantees the security of requests.
3. API Store / Developer Portal:
   • This component provides a place to keep APIs in a store or catalog, exposing them to internal and/or external stakeholders. The API store serves as a marketplace where users can subscribe to APIs, obtain support from the community, and access other relevant information.
4. API Analytics/Dashboard:
   • API management solutions offer analytics and dashboards that allow users to monitor API usage, load, transaction logs, historical data, and other metrics. This information helps in understanding the status and success of the available APIs, facilitating data-driven decision-making.

Now I’m not sure why I found this part so interesting and why I found myself watching a 30-minute YouTube video on how API dashboards work and operate, but hey whos going to judge? This is a section I believe we are going to cover/hope we do as it’s been a great experience learning how to build and read complicated APIs. I feel like I am ready to take another step and properly learn how I would manage one of these APIs that I created.

PS: “Advantages of API vs ******** ” (Stay Tuned)

Until Next Time

Source: https://medium.com/@krunalchauhan_/article-worth-reading-on-what-is-an-api-what-is-a-rest-api-and-deep-diving-into-rest-api-fea074dacaed

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

As a student navigating the intricate world of software development, stumbling upon Andreas Schöngruber’s insightful article on anti-patterns was like discovering a treasure map through the labyrinth of coding pitfalls. Titled “What Is an Anti-pattern?”, the article serves as a comprehensive guide to understanding, identifying, and avoiding anti-patterns in the software development lifecycle.
Schöngruber’s article begins by defining anti-patterns as deceptive solutions that appear effective but ultimately create more problems than they solve. These pitfalls manifest in various aspects of software development, from programming practices to methodological and testing phases. The article covers programming anti-patterns like Spaghetti Code, Lava Flow, Accidental Complexity, God Object, Hard Code, and Magic Numbers. It further explores methodological anti-patterns such as Premature Optimization, Reinventing the Wheel, and Copy and Paste Programming. The discussion extends to software testing anti-patterns like the Wrong Kind of Test, Testing Internal Implementation, and the Happy Path.

Why I Chose This Resource:

In the ever-evolving landscape of software development, understanding what to avoid is as crucial as knowing best practices. The article’s clarity in categorizing and explaining various anti-patterns appealed to me as a student eager to enhance my coding skills. It provides a roadmap to steer clear of common pitfalls and promotes a proactive approach to creating efficient and maintainable code.

Reflection on the Content:

As I delved into the programming anti-patterns, the concept of Spaghetti Code resonated with me. Schöngruber’s emphasis on modularity and readability struck a chord, prompting me to reflect on past coding practices. The discussion on Hard Code also resonated, making me rethink my approach to configuration management. The article prompted a realization that simplicity, adhering to the “Keep it simple, stupid” (KISS) principle, is not just a preference but a necessity.

Moving into methodological anti-patterns, the notion of Reinventing the Wheel made me reconsider some instances where I may have overlooked existing solutions. The discussion on Premature Optimization underscored the importance of balancing performance improvements with actual needs, a valuable insight for optimizing code efficiently.

Application in Future Practice:

Armed with the knowledge gained from this article, I envision a more discerning and proactive approach to my future coding endeavors. Recognizing anti-patterns will not only enhance the quality of my code but also contribute to a more efficient development process. I plan to integrate the principles discussed, such as modularity, simplicity, and avoiding unnecessary optimizations, into my coding practices. Additionally, the insights on testing anti-patterns will guide me towards more effective quality assurance strategies.

For those eager to navigate the labyrinth of software development with fewer missteps, I highly recommend reading Schöngruber’s article. It’s a valuable addition to any student’s toolkit, providing insights that transcend textbooks and delve into the practical nuances of writing robust and maintainable code. You can access the article with the link below.

https://www.baeldung.com/cs/anti-patterns#:~:text=Anti%2Dpatterns%20are%20the%20opposite,project%20management%2C%20and%20organizational%20behavior.

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://socpub.com/articles/how-can-cloud-computing-enable-remote-teams-work-more-productively-17895

https://aws.amazon.com/application-hosting/benefits/

https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-azure

From the blog CS@Worcester Alejandro Professional Blog by amontesdeoca and used with permission of the author. All other rights reserved by the author.