Category Archives: CS-343

Week 2 – Clean Architecture

Article URL: https://dev.to/moh_moh701/part-1-what-is-clean-architecture-4bn1

The article chosen, written by Mohamed Tayel, discusses a software design philosophy introduced by Robert C. Martin (Uncle Bob) called Clean Architecture. Mohamed’s article explains what Clean Architecture is and why it could be a good software design option. The goal of Clean Architecture is to create and build systems that are easier to understand, flexible in terms of scalability and modifications, and easy to maintain. Initially, he presents the main objective of Clean Architecture and later discusses the design’s principles, benefits, and key components.

Interestingly, Robert C. Martin’s (Uncle Bob) blog was one of the blogs I discovered a couple of weeks ago while searching for articles on Object-Oriented Programming. His blog contains a lot of great content and well-written articles on various Computer Science subjects. However, that is not the reason I picked this specific article to discuss today. After reading the first paragraph, I found myself engrossed in the article until the end. I have always been interested in finding ways to make my own code more readable and easier to maintain. I have been amazed by how Object-Oriented Programming, based on its principles, is very organized, making it easy to understand and modify. Clean Architecture seemed to me like a way to achieve similar benefits from Object-Oriented Programming in programs not built with languages that support it.

I honestly believe that Clean Architecture’s goals can be applied to any program. I am not trying to undermine Clean Architecture’s merit as an excellent way of designing programs, but I truly think that every program should be planned and built to achieve the five benefits Mohamed Tayel mentioned in his article about Clean Architecture:

  1. Improved Testability
  2. Flexibility
  3. Maintainability
  4. Reusability
  5. Scalability

I plan to incorporate its objectives and main characteristics into my next programs. Especially by applying two of Clean Architecture’s principle, flexibility and improved testability. Flexibility consists of building a software that can support changes to it (e.g. replacing a database or a web framework) with minimal impact to other parts. And Improved Testability consists of “decoupling the business logic from external dependencies, to achieve higher test coverage” (Mohamed Tayel).

Clean Architecture seemed to me as an attempt to implement certain Object-Oriented Programming principles in software built with languages that do not support it. Clean Architecture breaks down software into four layers: Entities, Application Core, Infrastructure, and User Interface. By breaking down the software and having each layer encapsulate another, it is very similar to OOP design.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

What is Technical Debt

The Future you Problem

Photo by cottonbro studio on Pexels.com

Hello and welcome to a new week on this beautiful blog of mine. Today is a topic that is of interest to me and possibly everyone reading this. It could also be something you ran into during a coding project. It is called Technical debt, which is the concept of delaying or omitting work to complete a project but cause more work to do in the end. 

Let me give you an example that I have dealt with, and that you may have also dealt with. So you got a coding assignment to do right and that deadline is coming fast. So you set out to do it in the quickest and easiest way possible without a care for code layout or etiquette, it is just you working on it after all. The next day, you think to yourself that you may need to rework some facets of the code to make it run better or make it look neater. You then open up the project and look in horror at the mess you made and realize that it would take more time and effort to make it neater or run better than it would be to just continue on and get the project done. That is technical debt and yes it accrues interest.

The example was more personal and not that bad when you realize that the only price you paid is something you can’t stand to look at and also something that will take a long amount of time to fix. Like I said before it is just you working on it and as long as it works it’s fine…but what if you weren’t alone, say what if you were working in a team of 2 or 4 or perhaps a whole company amount. Then we have problems. Cause not only the debt is put upon others, but even money can be a problem if it is a company involved. 

There is also types of technical debt. Planned Technical Debt is meant to establish one presence in the market or gather feedback from customers, kinda like prototyping from my understanding. There is also Inadvertent Technical Debt when the developer is unsure of market requirements or aware of the architecture. 

Many things can cause technical debt to happen, such as poor management or the code not being reviewed well enough.  So to avoid such things it’s a good idea to 

  • Understand the Requirements
  • Understanding Decision Consequences
  • Supervising the Process

So be careful when coding a project as it may come to bite you in the future, so take into consideration the future you and help you out.

Be a Better Dev. (2020a, October 5). What is Technical Debt? (as a software developer). YouTube. https://youtu.be/2nDxKYIajoU?si=crpLGeoCewYZ_kEj

Eye on Tech. (2020b, October 7). What is Technical Debt and Why Does Tech Debt Matter?. YouTube. https://youtu.be/cdzUXv8SpjY?si=FHZ0Vl6ZVkhuSNeE

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Week 1: Object-Oriented Design Principles

Sunday, September 15, 2024

This week I was introduced to Object-Oriented Design Principles. In this week’s blog, I will be discussing what object-oriented design principles are and how these principles help with creating software so that it is easy to maintain.

The Medium blog post by Ravi Patel “Understanding Object-Oriented Design Principles” offers an overview of major object-oriented design principles and how they help to the creation of successful and maintainable software. Object-Oriented Design (OOD) is a software design methodology that views the program as a collection of interacting objects, each representing an instance of a class. Ravi goes on to discuss the fundamental principles, encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is the process of grouping data and methods that operate on it into a single unit or class while restricting access to certain of the object’s components. This aids in concealing the internal state and requires all interactions to be conducted through an object’s methods.

Abstraction is the process of simplifying complicated systems by modeling classes based on key traits and behaviors, while obscuring unneeded information. This focuses on an object’s actions rather than its methods.

Inheritance allows a new class to inherit characteristics and methods from an existing class, enabling code reuse and establishing a hierarchical connection between classes.

Polymorphism allows objects to be viewed as instances of their parent class rather than their own. This enables the use of a single interface for a broad range of activities, increasing code flexibility and extensibility.

I chose this blog post because it helped me understand the principles better. After this week’s reading I now understand that object oriented principles is a theory that helps developers in how to think about and build code that is easier to work with, simpler to understand, and requires less maintenance overall. When working on my POGIL activity with my team this week, there was a question that asked us to define the principles without looking them up. We defined the principles as follows:

Abstraction is simplifying code
Encapsulation is adding code to already existing code
Polymorphism is many forms of code/methods
Inheritance are classes and their super classes and constructors

Our definitions were not entirely wrong. We could gather what each principle meant to an extent. I see myself applying these principles in my future projects. It would help create readable code that can also be modified easily as needed. This week’s material made me understand that not all long code is helpful. The simpler the code is the better it is for the next developer to read it. When I usually code, I add a lot of unnecessary code that does not need to be there. I hope to improve my code writing skills as I learn more.

Blog link: https://medium.com/@ravipatel.it/understanding-object-oriented-design-principles-0c1e48207c89  

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

GUI Architectures – Week 1

Looking back at this blog post it is a bit outdated, being posted nearly 2 decades ago but I still feel like it has a lot of quality information within it that can still be used today. I learned about several different architectures and their patterns that I thought were rather interesting. It was still a little over my head with a lot of jargon I didn’t understand, such as “Forms and Controls” and “Model-View-Controller” which is an apparently highly misconstrued architecture, that I had to look up, but I think this gave me a good look into what I can learn more about and where to direct my attention. I think in the future after I’ve learned some more basic architecture and design concepts, I’ll really be able to apply them and understand them more. Also, I’m a lot more interested in seeing more front-end things related to GUI and the process of developing a quality and useful GUI for a user. Now looking back at myself a little bit, reading this has really cemented for me how much I don’t know about the entire software development process. It truthfully shows me how I need to really pay attention and really work harder at developing my knowledge in the field as most of the blog post was entirely new to me and things I had never heard before which gets me excited about learning more! Also, all of the diagrams in the blog post were really neat and had a great effect in helping me understand the points of each pattern, so this has kind of helped me to understand how useful UML diagrams are and would be for designing and putting a program into and understandable and digestible format that makes it really simple to at a glance get what’s happening. I do think for my next blog post I may need to pick something a bit more my speed.

Summary: An interesting exploration of various architectures for GUI design and detailing their features as well as their underlying patterns within the architectures. Also is a sort of “intellectual history” of these varying GUI architectures.

Reason: I wanted to learn a bit more about GUI’s and how they work, this really details an almost historical record of UI development and how they work underneath. It also contains plenty of diagrams and detailed explanations that really helped me to better understand it.

Blog Link: GUI Architectures (martinfowler.com)

From the blog CS@Worcester – aRomeoDev by aromeo4f978d012d4 and used with permission of the author. All other rights reserved by the author.

Inheritance Problems

As the first blog post, and naturally occurring when at the start of my CS-343 class, I had a hard time picking a topic. In class we haven’t gone over many new concepts, but my professor did mention during a topic review that there are other options from inheritance that are able to do very similar functions. Piquing my interest, I wanted to look into inheritance itself and what other people thought of it and compare it to my experience coding programs using inheritance.

The blog post I chose started with an introduction about how inheritance is taught in a way that doesn’t give students the best grasp at how to implement some of the more niche situations or real-world cases where inheritance would be the most efficient method. Something that the blog mentioned that has been something that as a student I have never really come across, is deciding when a certain method, in this case inheritance, is the best way to solve a problem. Usually with assignments, the method is already predetermined, and the implementation is what you are graded on, or because of the limited subjects covered, the intended method is easy to figure out.

The author then goes into the two main problems that inheritance has, the complex syntax and the complexity of the problem inheritance is best suited to. Inheritance has it’s own syntax that is new and you have to learn but it also gets difficult because the new context of the code now has new rules to it that need to be considered such as precedence, overriding, and variable types. The other problem is that cases where inheritance would be the best implementation are problems that have a reasonable amount of complexity. There needs to be two classes of objects that have a good deal of similarity between them but also be different enough and have a good amount of shared code to where you would not want them to be two separate classes. 

Reading this blog as well as reviewing inheritance in class has shown me that while I know the concepts and am able to write a program that utilizes inheritance, my experience with all of the special cases and interactions is not complete. The blog was more catered to teachers but as a student I also found it to be helpful. The blog doesn’t offer much in terms of a deeper look into the topic or language specific examples, but having learned more about it’s complexity I will be sure to look at other resources that more thoroughly and meticulously go over the nuances of inheritance so that I can feel confident in implementing it in any program where it would be a proper fit. I think it’s always good to try and fully understand a topic especially when you think you know everything about a topic and you run into a roadblock. 

Teaching Inheritance – Ada Developers Academy

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

Navigating the Upgrade of Outdated Codebases: Insights from Increment

In the world of software development, maintaining and upgrading outdated codebases is a challenge. That’s the reason why I chose this blog post titled “Ask an Expert: Upgrade Outdated Codebase” by the Increment team. Given that this topic directly relates to when class CS348 did an gitpod assignment on software maintenance. I’ve seen many other peers recommend this article as it offers expert advice on how to approach and successfully execute upgrades to aging codebases, ensuring they remain functional and relevant. When you’re faced with these questions, should you make the change, when should you make the change, finally how should you make the change. 

The Increment blog post provides 3 optional & practical strategies for modernizing outdated codebases. 1. A Big Bang Rewrite (changing the codebase from scratch and cutting over all users in a single conversion). But of course, this has its cons, such as being time-consuming and not seeing the process unless it’s all finished. 2. Tack the New onto the Old. The second option is to add new features built with new technology to the existing codebase. However, it’s not like you can just add in a new feature with the old and not touch up the old feature at all.  Outdated features are outdated for a reason, there has to be a balance. 3. A Hybrid Approach. Why choose one, when you can do both? Rewriting your entire codebase is a drastic and often un-recommended move. Adding new features to an old codebase is usually more manageable but can lead to serious issues. Therefore, finding the in-between. This option requires changing out the whole of your old code. But unlike the first option, the rewrite should be spread out over a period of time to minimize technical debt and financial cost. However, all these solutions have side effects, including this one. While you are updating, the technology could continue to advance and you’re left trying to catch up all over again or the specifics/goal changing as you are.

I really appreciate how the creator goes about explain their reasoning. I personally follow the motto: if it isn’t broken, don’t change it. But the way the blog presents actionable advice from industry experts, which is crucial for understanding the best practices in managing and modernizing legacy systems. Made me shift my thoughts a little. Change it before it becomes broken. As quoted from the blog, “it’s probably your last chance to fix the technology before it becomes irreparably broken.” 

Given that this topic directly relates to our course material on software maintenance and evolution, the insights provided are both relevant and timely. One key takeaway from the article is the importance of documenting the existing codebase before initiating any upgrades. Maybe even make another copy, it would be terrible to find out your “updates” ended up making things worse than before you decided to change it. This is definitely something I can expect to apply to future practices. 

I have learned a lot from this blog and for further reading, you can access the original blog post here.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

Welcome to Software Construction, Des & Architecture blog.

In this blog will be talking about the aspects of software construction, design and architecture aspects.

When building software, three important aspects to consider are construction, design, and architecture. Construction is about writing the actual code that makes the software work. It’s like putting together the pieces of a puzzle to ensure everything fits and functions correctly. Design is like planning the layout of a house before you start building. It involves figuring out how different parts of the software will work together, making sure everything is organized and easy to use.

Architecture is the big-picture plan for the software, similar to designing the overall structure of a building. It decides how all the different pieces fit together and interact with each other. Good architecture ensures the software can handle changes and grow over time without falling apart. By focusing on construction, design, and architecture, developers can create software that’s not only functional but also easy to maintain and expand in the future.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Welcome To CS-343

Hi welcome to my first blog post for CS-343.

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Starting the year off!

Welcome to my first blog post! My name is Andi Cuni and I am a senior completing my undergraduate CS degree. Starting my journey blogging with a background in computer science and software development, I am excited for this transition, and I plan to share everything that comes along my experiences to see if others relate as well!

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Initial Post

This blog will be about my progression and learning I do with the material used within the class and how I use it in class projects, as well as how I use the material with my own personal projects.

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