CST-338 Wk03 Learning Journal: Project 1 Code Review

Was any part of the code a struggle for YOU?

Yes, ensuring that the attack() method worked properly with type effectiveness and damage computation was the most challenging aspect. I had to go back and make revisions to my handling of the modifier logic many times. Verifying that takeDamage() and isFainted() were appropriately and conflict-free updating the monster state was another challenging aspect. Sometimes a monster's HP was negative, or it wasn't fainting as it should have.

Was any part of writing the code easy for YOU?

It seemed really simple to create the base Monster class and write the constructors, getters, and setters. Using the Google Java Style Guide also made it simple for me to generate formatting that is clear and consistent. After I discovered the proper flow between the abstract class and the subclasses, the class structure became apparent.

What is your biggest victory?

A biggest victory for me was getting the attack() function to apply type modifiers, output the sentence appropriately, and pass the pertinent unit tests. Making my code clear and adhering to sound design principles—such as utilizing accessors rather than directly changing fields also made me feel good.

Who did you work with?

I worked with Ethan, Liam, and Matthias C

What improvements would you make to your code / what was suggested?

Ethan suggested improving method-level comments and eliminating unnecessary imports. Liam suggested using a switch or mapping technique to streamline my setPhrase() code. I also discovered that by shifting certain functionality to helper methods, I could cut down on repetition.

Which unit tests were the hardest to pass?

The most challenging unit tests were defensive computations and battle logic, particularly when attack and defense values were produced at random. AttackPointTest and defTest were especially annoying until I perfectly matched my reasoning with the guidelines.

A. How do the existing tests function and could they be improved?

The tests are useful for confirming predicted behavior and outputs, particularly for attack and fainting logic. However, I believe they may be improved by looking at edge circumstances, like healing or attacks from fainted enemies.

B. Do the existing unit tests cover the full range of Book and Reader functionality?

Tests might need additional edge cases, but they cover the fundamentals of inheritance. They confirm that subclass functionality functions with the Monster superclass, although validation would be strengthened by more polymorphism tests.

C. How would you change the unit tests?

More boundary situations, such as when a monster has one HP or when many modifiers stack (for example, an Electric monster fighting a Water-Grass hybrid if that were permitted), are something I would include. Moreover, I would test for monsters attacking themselves and what would occur in such scenario.

What did you struggle with?

I found it challenging to comprehend how the various class components were supposed to work together without being specifically mentioned in the test results. Until I made a simple graphic, it was also difficult to follow the logic flow between attack(), takeDamage(), and calculateDefensePoints().

What did one of your teammates struggle with?

Liam mentioned that he had difficulty comprehending the type modifier reasoning and that one of his monsters was not using the appropriate damage multiplier. Ethan mentioned to have difficulty obtaining toString() to provide the right text without resulting in test failures.

What are you most proud of on your submission for Project 1?

Being organized during this endeavor is what I'm most proud of. For each part, I utilized clean Git branches, avoided overcomplication, and maintained legible logic. It was satisfying to see my work pass evaluations and receive encouraging comments from colleagues.

Comments

Post a Comment

Popular posts from this blog

CST 334 Week 5

This week in CST 334, Virtual memory rules and the operating system's handling of page replacement under memory strain were the main topics of discussion. When physical memory is full and the OS has to choose which pages to remove to create room for others, I discovered how important these policies are. We focused on four main algorithms: Random, Optimal, FIFO (First-In-First-Out), and LRU (Least Recently Used). These policies are essential for maintaining system responsiveness and preventing excessive disk usage when multitasking with large processes. Because it depends on future information of memory access, the optimal replacement strategy, while ideal, cannot be applied in practical systems. Nonetheless, it provides a useful standard by which to compare actual policies. Because of Belady's Anomaly, which states that expanding memory might actually result in more page errors, I discovered that the FIFO technique was shockingly incorrect. By utilizing the idea of temporal l...
Read more

CST 334 Week 6

We studied semaphores and monitors this week in CST 334, two crucial synchronization primitives for concurrent programming. Particularly intriguing to me were semaphores, both conceptually and practically. Semaphores are shared integer variables that regulate thread-to-thread access to shared resources. The basic POSIX functions acquire () and release () (or wait () and signal() were covered, along with their applications in establishing thread coordination and mutual exclusion (mutex). I liked how the operating system makes sure these actions are atomic, removing busy waiting by stopping inactive processes. The notion became much more robust when semaphores were used to handle issues like the parent-child thread synchronization or the producer-consumer situation.The usage of locks and condition variables in the development of semaphores (such as the "Zemaphore") was also helpful to me in comprehending how lower-level processes contribute to higher-level synchronization tools...
Read more

CST 334 - Week 7 Journal Entry

This week,I learned understanding of how operating systems control file systems and storage devices, beginning with how the system communicates with input and output devices. I now recognize the crucial functions that interruptions and polling play in device communication. Polling may be time-consuming, particularly for slower devices, as it requires the CPU to continuously check if a device is available. In these situations, interrupts are more effective since they let the CPU focus on other tasks and only react when the device indicates that it is finished. I saw how Direct Memory Access (DMA) enables the device to manage data transport directly, lowering CPU involvement and enhancing system efficiency while transferring large volumes of data. Additionally, I discovered that memory-mapped I/O simplifies communication by enabling device registers to be accessed similarly to memory addresses. The structure and optimization of disk storage was another subject that caught my atte...
Read more