This topic explores object-oriented programming (OOP) concepts like polymorphism, inheritance, and design patterns, showing how these very basic core concepts create reusable code. In particular, the Gamma et al. book demonstrates practical use of polymorphism and abstract classes to define flexible software structures, while the OpenGL guide shows examples of implementing modular systems, such as game engines, where different objects share common behaviors but have distinct implementations. I chose these materials because developing flexible and scalable gaming systems needs an understanding of polymorphism and inheritance. Multiple character types, enemies, weapons, or objects that behave differently yet have similar functions are frequently included in video games. These resources make it easy for developers to build clear, modular code while handling complex interactions between game objects.

               With polymorphism, game developers can regularly allow different objects while each of them behaves uniquely. For instance, a role-playing game (RPG) may have several characters: Warrior, Mage, and Archer. They get from the common Character class that describe methods like Attack(), Move(), or TakeDamage(). Each subclass overrides Attack () to implement uneasy behavior: the Mage cast spells, the Warrior swings a sword, and the Archer shoots arrows. Without polymorphism, coders would use a lot of conditional statements like if (characterType == “Mage”) … else if (characterType == “Warrior”) …; this goes against Open-Closed Principle (OCP), making it difficult when adding a new character. Using inheritance and polymorphism, the addition of a rogue class would require only the implementation of the Attack() method, while existing code would remain the same.

I believe the contrast between conditional logic and polymorphism in game AI to be instructive. In simple projects, using conditional statements to handle various opponent actions could work, but as the number of characters, skills, and interactions increases, the code rapidly gets crowded and challenging to maintain. In contrast, polymorphism enables any type of enemy—such as a dragon, goblin, or mage—to implement its own action while staying handled by the game engine as a generic enemy object. By using this method, AI action becomes versatile, modular, and simpler to expand, allowing for the addition of new challenge types or unique attacks without requiring changes to the current code.

In the future, I want to use these ideas to develop generic avatar and item systems for my personal projects so that new content can be added without having to rewrite the logic. The usefulness of proper object-oriented design in real-world game production is proven by observing how these concepts are implemented in professional game engines like Unity and OpenGL, which close the gap between theory and practical application.

References

1. Design Patterns: Elements of Reusable Object‑Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides — Addison‑Wesley, 1994. Link: https://www.oreilly.com/library/view/design-patterns-elements/0201633612/ O’Reilly Media+1
2. OpenGL® Programming Guide: The Official Guide to Learning OpenGL® Version 4.5 with SPIR‑V by John Kessenich, Graham Sellers & Dave Shreiner — Addison‑Wesley Professional, 2016. Link: https://www.oreilly.com/library/view/opengl-r-programming-guide/9780134495514/

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

In software development, simplicity is further required in coding. It is the foundation of how software genuinely works. Every line of code we write in system, from short programs to large systems, teaches us one major lesson: keeping code simple leads to stronger, cleaner, and further reliable software. When code is simple, it becomes easier to understand how each part of a program interacts, how data flows through the system, and how changes can be made without breaking additional components.

Throughout our computer science class, we learn that writing code is not just about making something run, it’s about designing how it runs. Concepts like encapsulation, abstraction, and modularity form the heart of this process. Encapsulation keeps data protected and managed within defined boundaries. Abstraction allows us to hide unnecessary details so that only the important parts are visible to the developer. Modularity divides complex programs into smaller, independent sections that can be developed, tested, and improved separately. These principles not only make programs easier to understand but also reflect how big software plans are built in real-world projects.

Simplicity also plays pivotal role in collaboration. When multiple developers work on the same clear and consistent code, it allows everyone to read, modify, and contribute without confusion. In our group projects, clear code helps everyone understand and contribute easily. Even when we continue working from home, the project feels simple and organized, not stressful. This clarity saves time, reduces errors, and keeps teamwork smooth.

Another reason simplicity matters are maintenance. As we study different programming software models, we see that maintaining complex code can become easy to modify and frustrating. Clean, readable code allows group members to trace logic quickly and identify issues before they cause system failures. This is why experienced programmers often say, “Code is read more often than it is written.” The goal is not to write the most advanced or impressive code, but to write the most understandable and dependable one.

Keeping code simple also encourages better thinking. It forces us to focus on problem-solving rather than decoration. By keeping things simple, we learn to study the requirements carefully, organize the program’s structure wisely, and create efficient code that works effectively without unnecessary lines. Simplicity shows real understanding of how software functions at its core.

As I continue learning software design, I realize that simplicity is not the opposite of intelligence, it is the best outcome of experience and clarity. The coders don’t make code complex; they make it clear. True creativity in programming lies not in how much we write, but in how well it makes as simple—and that always begins with keeping the code simple.

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.

I came across an article on Titled “Encapsulation in Object Oriented Programming”. It Explores in detail about the core principles of object-oriented Programming (OOP): encapsulations. Although I had already heard about this concept in computer science class, that time just covered the minor details and definition without really understanding why it is so important in practice. Reading this article helped me see encapsulation in a new way, especially through real-world examples and comparisons that made the idea much easier to grasp.

               Encapsulation is explained as hiding the internal details of a class and only allowing controlled access through methods. This is usually done by keeping variables private and providing getters and setters for interaction. According to the article, errors can easily occur when other program pieces change an object’s state directly in the absence of encapsulation. However, with encapsulation, updates are subject to predetermined guidelines, maintaining the system’s unity and security.

               One of the examples that stood out to me compared encapsulation to locking a house. If all the doors and windows are left open, anyone can come in and move things around. In programming terms, that would be like exposing all fields of a class as public. By contrast, encapsulation is like keeping the house locked and only providing a few keys for safe entry. In the same way that you wouldn’t give full write access to everyone on a GitHub repository, you don’t want every part of a program to freely change the internal state of your objects. Instead, you provide limited access—like adding collaborators with specific permissions or using pull requests for controlled changes. This analogy helped me understand why developers stress the importance of data hiding: it keeps things organized, prevents misuse, and ensures that changes happen in a safe, predictable way.

               The article provided an actual scenario using a bank account class. Any piece of code might set a balanced variable to a negative value if it is public, which would go against the program’s logic. However, the application may set restrictions like “balance cannot go below zero” if the balance is private and is only accessible via the deposit() or withdraw() methods. This demonstrated to me how encapsulation guarantees that critical rules are always observed while also hiding information.

               What I learned from the article is that encapsulation goes beyond coding style—it’s about safeguarding data and ensuring programs behave correctly. A helpful way to picture it is how GitHub handles collaboration. Instead of letting everyone edit the main project directly, contributors usually fork the repository, make changes in their own copy, and then open a pull request for review. This process keeps the main branch stable while still allowing improvements, like what we practiced in our CS343 and CS348 classes at WSU.

               Overall, the article provides the details we need to practice and build stronger knowledge in the basics of the field.

References:

“Encapsulation in Object Oriented Programming” by AKshay Raut (Medium)
https://akshayraut.medium.com/encapsulation-in-object-oriented-programming-4cfb0ee28f12

FreeCodeCamp. (n.d.). The Four Pillars of Object-Oriented Programming. https://www.freecodecamp.org/news/four-pillars-of-object-oriented-programming/

From the blog CS@Worcester – Pre-Learner —> A Blog Introduction by Aksh Patel and used with permission of the author. All other rights reserved by the author.