Category Archives: CS-343

Reflecting on the Core Pillars of Object-Oriented Programming: Insights from a Recent Exploration (Week-14)

In my recent exploration of Object-Oriented Programming (OOP), I came across an insightful blog post titled “Unraveling the Mysteries of Object-Oriented Programming: A Deep Dive into its Core Concepts.” This blog, written with clarity and depth, provided an in-depth look into the foundational elements of OOP – Abstraction, Encapsulation, Polymorphism, and Inheritance.

The original blog post broke down the complex principles of OOP into digestible segments, explaining each concept’s significance and application in software development. It began with Abstraction, describing it as a method for simplifying complex systems into essential characteristics. Encapsulation was then introduced as a means to protect data integrity by bundling data and methods within a class. Polymorphism was highlighted for its flexibility in allowing different classes to be treated under a common interface. Finally, Inheritance was discussed as a tool for building new classes from existing ones, promoting code reuse and efficiency.

Reflection on the Blog’s Content:

I found the original blog post remarkably enlightening. The way it articulated each concept with relevant examples made OOP’s sometimes abstract principles more tangible and relatable. Particularly, the explanation of Polymorphism and how it enhances flexibility in programming was an ‘aha’ moment for me. The post’s structured approach in dissecting each principle separately yet showing their interconnectedness provided a holistic understanding of OOP.

Application in Future Practices:

The insights gained from the blog will significantly impact my approach to software development. The understanding of Encapsulation will guide me in writing more secure and robust code, emphasizing the importance of data protection. Additionally, the concepts of Inheritance and Polymorphism will be instrumental in designing more versatile and maintainable code structures, enabling me to tackle complex programming challenges more effectively.

The blog’s detailed exploration of Abstraction has particularly equipped me with a strategic approach to problem-solving. By focusing on the essential elements of a problem, I can better manage complexity and enhance the clarity of my code.

Conclusion:

This reflection on the foundational concepts of OOP, as explained in the initial blog post, has been both educational and transformative. It has deepened my understanding of OOP’s core principles and their practical applications in real-world programming scenarios. As I continue my journey in software development, the insights from this blog will undoubtedly serve as a valuable guide in crafting efficient, robust, and maintainable software solutions.

Resource Reference:

“Unraveling the Mysteries of Object-Oriented Programming: A Deep Dive into its Core Concepts.” Blog post,. https://codedamn.com/news/javascript/oop-best-practices .

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

Week 14 – Token #2 – CS-343

For this blog, I specifically wanted to look into how this class relates to the preferred field I want to go into, which is Game Design. I wanted to see what kind of languages would be used, what kind of design elements are implemented, and even in the case of frontend vs. backend, how online games employ servers.

However, it seems like I had a misunderstanding that these two positions were similar omewere, as I find many sources that say software design vs. game design are a completely different beast, which only made me more interested. I did some more research, and this lead me to end up reading this article below:

Software Engineer vs Game Developer – Which one is for you?

Specifically I noticed that software development has more rigidity when it comes to designing and delivering a product. Software engineers are usually employed to design a software to meet consumers demands, which usually entails specific features and options they’d want in the software you’re developing. Whereas with game design, you have a much more flexible development cycle, as theres a lot more creativity involved. You’re less focused on making sure specific features are available and more focused on delivering a product that is unique and interesting for consumers, and keeps them engaged.

Game developers also rarely work with programming languages when it comes to development of products. Game developers mainly use engines, which are interfaces that employ programming languages to create building blocks to build off of to create a video game. Software engineers mainly work with the code directly at almost all times, making sre each line is properly written. That’s not to say some game devs don’t work with code directly, some do, and many Triple A companies actually write their own engines using their own code, like in the case of Epic Games’ Unreal Engine, which is used to power their famous game Fortnite.

Something this article notes is that software developers may not need to worry about performance compared to game developers, and I can understand why they might say that. Games rel on having a fluid and enjoyable experience, and that is dependant on the performance of a game, making sure theres no glitches, bugs, or lag. However, I would argue that performance is still a factor within software design too, because what if a simple calculation process in a program takes multiple minutes? Consumers will still have an issue with that. While I do think it’s definitely a lot more important in game development, that’s not to say it’s not unimportant in software design.

And that’s all my blogs for this semester! I’ll be taking another of Professor Wursts classes next semester, so I’ll likely be writing again then. See all you readers come January!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14 – Token #1 – CS343

For this blog I’ll be using one of my tokens for this class so I can hit the 6 blog minimum before the semester is over.

In this blog post, I wanted to look more into JavaScript since I didn’t really know too much about it. I struggled with the backend homework we had because I never knew anything about the syntax or language at all. So, I want to learn a bit more about this language within this blog. For this, I consulted this website, and gave it a good hearty read:

https://developer.mozilla.org/en-US/docs/Web/JavaScript

This site gives an overview of JavaScript and the applications in which it is used in general, and what benefits and downsides it has compared to other languages.

What I found very interesting is that I originally knew that JavaScript was mainly used for website development and coding, but this site gave some examples of applications such as Node.js and Adobe Acrobat. I believe we’ve actually utilized Node.js before in our classes, but I can’t quite put my finger on what exactly we used it for, but I recgonize the name appearing in one or more of the repositories we’ve been working with.

It seems like JavaScript is much like Java in the sense that it can use object oriented code, but I think the similarities between the two end there. In the past, I always heard that JavaScript was a completely different beast from Java, and after look more into it, I see why. This site below describes the differences:

https://www.lighthouselabs.ca/en/blog/java-vs-javascript

JavaScript it object-orientedcode, whereas Java is object-based. That may sound the same as each other, but there is some very specific distinctions between them. Java relies on objects to function, whereas JavaScript has functionality for objects and suggests use of them with it’s language, it is not required. JavaScript is also a lot more fluid with it’s syntax, and has a lot more free-form and flexibility with it, which reminds me a lot of what I’ve heard about Python. Java is a lot more rigid, and requires specific pre-set uses of it’s syntax.

But back to JavaScript, it seems like its The language for web design, as a lot of it’s language is made with web design in mind. My future for this area of study is some form of design in technilogical areas, so it would be possible I go into Web Design. If I do, I’ll definitely have to teach myself more JavaScript. It seems like a really useful language to have on hand in that case.

I will be posting one other blog today, using another token, so stay tuned for another!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 14: CS-343

Design Patterns

A design pattern is a general solution that can be used to solve commonly occurring problems in software design. A design pattern cannot be put directly into code, rather it is a template of how to solve a problem that can be used various situations.

Design patterns are helpful as they speed up the development process by providing proven examples to be used as a reference for common problems. When designing software, small subtle issues can build up leading to major problems that can only be seen during implementation. Using design patterns can help prevent these subtle issues from occurring which reduces the likelihood of major issues occurring.

Because design patterns are tested, proven, and commonly used, patterns also allows for better communication among developers by using well known and understood names for software interactions.

Types of Design Patterns

Creational

Creational design patterns cover class instantiation. These patterns can be further divided into two classifications, class-creation and object-creational patterns. Class creation uses inheritance in the instantiation process, while object creation uses delegation to create objects. Some creational design patterns are:

  • Singleton
    • A class where only a single instance can exist
  • Factory Method
    • Creates an instance of several derived classes
  • Object Pool
    • Avoids expensive acquisition and release of resources by recycling objects that are no longer in use

Structural

Structural design patterns are about class and object composition. Like creational patterns, structural patterns can also be broken down into class creation and structural object patterns. Class creation patterns use inheritance to compose interfaces, while object patterns define ways to compose objects to obtain new functionality. Some structural patterns are:

  • Adapter
    • Matches interfaces of different classes
  • Private Class Data
    • Restricts accessor/mutator method access
  • Decorator
    • Adds responsibility to objects dynamically

Behavior

Behavior design patterns are about how objects communicate with each other. Some examples of behavior design patterns are:

  • Null Object
    • Used to act as a default value of an object
  • Chain of Responsibility
    • A way of passing a request between a chain of objects
  • State
    • Alter an object’s behavior when its state changes

Conclusion

This article was chosen because it clearly described what design patterns are, what they are used for, and gave examples of the different types of design patterns. As stated before, not only does the usage of design patterns help with preventing major issues, they also allow for better communication among developers which is essential to a team’s success which is why I chose to write about design patterns. As I continue to design software, effectively using design patterns will become more and more prevalent, so learning about them now will only be beneficial.

Resources:

https://sourcemaking.com/design_patterns

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.

Javascript Code “Smells”

In this blog, I will go over the code “smells” pertaining to the Javascript language. For this topic, I picked a specific blog post called “Javascript Code Smells: 7 to Watch out For” written by .NET software developer Carlos Schults. It delves into this topic with lots of general details that explain some bad coding practice that can lead to your code having many problems. One of the main points that the blog emphasized was that long code alone was not a bad thing rather, the difficulty of reading lines of code that became too complex to handle makes these coding “smells” important to look back on when writing code.

The reason why I picked this topic is because I have had trouble with Javascript that I had never experienced before with other programming languages such as Java or C. One of the biggest factors that made it harder to understanding Javascript was its different and more difficult use of syntax. One of the coding “smells” the blog goes over was the difference in using the equality operand in Javascript compared to Java. Since I have been more involved with other programming languages such as Java than Javascript, learning the different coding structures of Javascript was going to take a while for me to grasp, especially since coding software such as OpenAPI uses Javascript to define its data and endpoints.

My main takeaway after reading this blog was that I should continue to further explore Javascript, while also maintaining the knowledge that I currently have when it comes to organizing the code I write. Reading this article about Javascript coding “smells” was very reassuring since I may have to find a similar reference to keep my coding consistent even after learning Javascript and not let it worsen with more and more complex functions for future coding. Having already had lots of experience with other programming languages in the past, I can use what I have learned from this blog and make better use of Javascript moving forward. 

Reference: https://www.testim.io/blog/javascript-code-smells/

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

Week 14 – Blog for both CS-343 AND CS-348

So for this blog, I wanted to find a topic that is applicable to both classes, so I wanted to look more into GitHub and the ways it functions compared to GitLab.

I duplicated by Secret Santa Generator repository from GitLab: https://gitlab.com/worcester/cs/cs-348-01-02-fall-2023/students/bpoole/secret-santa-generator and duplicated it in GitHub here: https://github.com/TempuraShrimple/Secret-Santa-Generator

To do this, I had to open up the local repo on my PC, create a new blank repository on GitHub, and run the following commands:

Once this was done, my repository was transferred over to GitHub successfully, without harming my GitLab repository in any way shape or form. Everything, including the history of the repository, was included with this transfer, which I think is really cool.

One difference I immediately noticed between GitHub and GitLab is that GitHub allows you to add a short description on the right-hand side of the repository, allowing a quick way to figure out what the program intends to do without having to look at the README.md. Obviously if you want more information, the README.md is very important in that case.

Both sites have a really good planning structure, with GitLabs’ issue boards, and GitHub’s project tab, which is structured very similar, but I think GitHub’s might be better as it allows you to choose from a lot of different templates like Kanban, Team retrospectives, and bug tracking, which I think is really cool. You’re also able to customize it as you please, so you’re able to set up a scrum structure like we did in GitLab for many of our projects. However, after looking into it, if you want to utilize Scrum, it seems GitLab is definitely structured better with preset pillars that are made with Scrum in mind. However, it’s a toss up on which would be better to utilize in this case for project management, in my own humble opinion.

GitLab also has some advantages in the construction and development aspects of this comparison, as after looking into it, GitLab is able to automate releases and builds of code once they are ready to be done so, and GitHub doesn’t have this capability at all.

https://about.gitlab.com/competition/github/?stage=Configure

This seems extremely useful for a program that has set deadlines and not enough time to do these things during, say, a Sprint. It allows a lot more flexibility with the work being done in a repo and can allow a lot more efficiency and productivity. I will definitely look into this more later on when I start using this repo I cloned myself.

All in all, after looking things over, it seems like GitLab has a lot of additions that make it better over GitHub in all sorts of ways, and I’m surprised GitHub is used more than it. I should probably introduce my friend I’m working with on GitHub for his game engine for this if he ever develops a much bigger team, as many of the planning-oriented inclusions GitLab has would be extremely beneficial!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Adhering to the Law of Demeter

Also known as the Principle of Least Knowledge, the Law of Demeter states that objects should avoid accessing data and methods that belong in other classes and instead, only interact with its immediate dependencies (Baeldung).

When used with Object-Programming languages, the goal of the Law of Demeter is to make the components of a program less dependent on each other, loosely coupled, and therefore easier to manage and scale.

There are five rules to the Law of Demeter:

  1. The first states that methods should only call methods that belong to their same class. It is not recommended for a method in class X, for example, to call on another method in class Y.
  2. The second rule expands on the first to say that methods of a class should only call methods that belong to the objects created by that class. For example, a method X of a class Z should only call methods of an object created by method X.
  3. The third rule states that a method should only ever interact with an object when passed to it as an argument. There should be no direct access to the object within the method itself.
  4. The fourth rule allows the method of a class to invoke the method of a class given that it is an instance variable of the same class. For example, method X of class C is allowed to call the method of an object held as an instance variable of C.
  5. The fifth rule is similar to the fourth rule except it states that the method of a class is able to call the method of a static field in that same class, similar to a method of an object of the same class.

When these rules of the Law of Demeter are applied, they help prevent code from becoming tightly coupled, meaning that they cannot operate independently. However, there are some exceptions to certain cases such as for chain calling, fluent APIs, or working with data structures. An experienced programmer will know when and how to effectively apply the law of Demeter.

While refactoring the code for one of my research projects, I had practiced to apply the GRASP principles to the new design. For another project that I am refactoring, now that I am more comfortable with the GRASP principle, I will focus more on applying the law of Demeter to make sure my code is not tightly coupled. This means code that is less fragile, scalable, and easier to manage.

Source: https://www.baeldung.com/java-demeter-law

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

api uses

Starting the Docker service also starts the Docker Daemon. However, if you receive the “Cannot connect to the Docker daemon” error, the daemon may have failed to initiate.

Use the following command to run the daemon manually:

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

Inversion of Control

Inversion of control is a software principle that asserts a program can benefit in terms of testability and usability if the management of an application’s flow is transferred to a different part of the program. I.O.C’s framework takes the management of an application’s implementation away from the developer. When interactions require custom business logic, the I.O.C framework will use the code provided by the developer. This is the “inversion” point of the inversion of control design principle. The most common application for Inversion of control is Java servers faces. I.O.C frameworks implement low-level and problem-prone activities, it allows the developer to focus on custom business logic instead of tedious tasks.  The one thing about inversion of control is that it can confuse what qualifies as an I.O.C and what doesn’t. Some examples of inversion of control are event-based user interfaces, shared cache, and comprehension framework—the range of development changes that qualify as I.O.C contributes to the term. I.O.C is a principle, not a design pattern- the implementation depends on the developer. I.O.C just provides high-level guidelines. Inversion of control and dependency injection are usually used interchangeably. Dependency injection is one implementation of I.O.C., it’s a technique that allows objects to be separated from other objects that they depend on.

Dependency injection suggests that instead of making an instance of class b into class a using the new operation, the object of class b should be placed into class a using one of these methods constructor injection, setter injection, and interface injection. Another example of implementation in I.O.C is the spring framework. That contains instances and manages the lifecycle of the objects in the program. The user in the configuration file provides information that relates to what objects and dependencies are used by the application like Java code. The benefits of Inversion of control are that it makes the application easier to test and maintain, reduces the amount of application code, and decreases the coupling between classes. Inversion of control helps make your code more readable because of the absence of some components. At the end of the day, I.O.C is a design pattern that is very useful for software development and lets us know when action needs to be taken when something happens in our system.

https://www.theserverside.com/definition/inversion-of-control-IoC

https://www.educative.io/answers/what-is-inversion-of-control

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.

From Learning to Doing

This week I was searching for an article to write about and I stumbled upon an article from Codecademy sharing the story of Juan Paredes, a Full-Stack Engineer from Mexico. The article is an interview of sorts where Juan has responded to prompts related to his journey from a Call Center Supervisor to a Full-Stack Engineer.

Juan covers how exactly he got into software engineering. When first moving to Mexicali, Mexico he got a job as a call center specialist. After 3 years Juan was promoted to Operations supervisor where at this point he decided to expand on his love for computers and wanted to start learning how to code through a free course on Codecademy.

After completing the free course, Juan decided to pay for a subscription and before Juan was completed with his first paid course, he was able to find an entry-level developer position. After figuring out that software engineering is what he truly wants to do, he also started attending the Mexicali Institute of Technology and is currently studying to obtain a degree in Software Engineering.

Juan also talks about how limited time and a pay cut made things temporarily more difficult but between his passion and determination, Juan continues to learn and progress.

When the article was created, Juan had just found a job with better pay and benefits than his first position and continues to progress forward in the software field.

Juan finishes off his remarks by recognizing the importance of organization and being open to learning new things as traits that will carry you far in the field. With organization, one can more easily find how to and be able to implement changes and by keeping an open mind you may learn things that while not valuable at the present, could become of great use in days, weeks, or months later on.

After reading this article I wanted to share and reflect upon it since I could relate to Juan. I too discovered my interest in programming through another medium of computers, however mine was video games. I started my journey by wanting to learn how to script in Lua for Garry’s mod addons and after that, I gradually kept learning more about coding. I never saw it as more than a hobby at the time, but here I am today almost finished with my Bachelor’s in Computer Science and preparing to join the workforce soon. Juan’s story serves as a reminder that through determination and perseverance, I can learn and do whatever I want within the extensive computer science field after obtaining my degree. It may take time, but in the end, the hard work will pay off regardless of how hard it may be or how much I would want to give up.

Article Link: https://www.codecademy.com/resources/blog/from-call-center-sales-representative-to-full-stack-engineer/

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.