This week involved learning about object-oriented programming, and writing a fun casino slot machine simulator for the weekly assignment.
I thought the assignment was a good exercise in working with classes and objects, although personally if I had the freedom to completely change method signatures and control flow logic as I pleased I probably would've come up with a drastically different solution. Additionally, the software tester in me wrote a couple of unit tests for my own personal amusement that performed 20 - 40 spins randomly, along with random inputs of -10 to 100 as inputs. The unit tests worked fine as well as the manual inputs I used to test the program as well.
Object-oriented programming is great, but I have actually more experience working in languages that aren't based on object-oriented programming. My first programming language and class was C, and since then I've taken multiple classes in that language itself. I've written several basic programs in C and I've practiced working with pointers, allocating heap memory, and dereferencing pointers (which I've failed at many times as a beginner). Additionally, I've taken a class in an even lower level language, x86 assembly. I don't find x86 assembly in itself very difficult, but it is incredibly tedious even compared to something low level like C. My rule of thumb with x86 assembly is that "if it takes 2 lines of C code, it probably takes 8 in assembly." Additionally, I work around a couple of embedded systems developers who seem to know their registers and stack pointers like the back of their own hands. It's quite amazing to see them work with low level code sometimes.
The only experience I have with UML diagrams is reverse engineering them when working with schemas in MySQL workbench. Because I like to visualize things, I find them quite useful when working with complex projects or structures because it makes it easier to see how every piece fits together to make one or several end solutions work.
I thought the assignment was a good exercise in working with classes and objects, although personally if I had the freedom to completely change method signatures and control flow logic as I pleased I probably would've come up with a drastically different solution. Additionally, the software tester in me wrote a couple of unit tests for my own personal amusement that performed 20 - 40 spins randomly, along with random inputs of -10 to 100 as inputs. The unit tests worked fine as well as the manual inputs I used to test the program as well.
Object-oriented programming is great, but I have actually more experience working in languages that aren't based on object-oriented programming. My first programming language and class was C, and since then I've taken multiple classes in that language itself. I've written several basic programs in C and I've practiced working with pointers, allocating heap memory, and dereferencing pointers (which I've failed at many times as a beginner). Additionally, I've taken a class in an even lower level language, x86 assembly. I don't find x86 assembly in itself very difficult, but it is incredibly tedious even compared to something low level like C. My rule of thumb with x86 assembly is that "if it takes 2 lines of C code, it probably takes 8 in assembly." Additionally, I work around a couple of embedded systems developers who seem to know their registers and stack pointers like the back of their own hands. It's quite amazing to see them work with low level code sometimes.
The only experience I have with UML diagrams is reverse engineering them when working with schemas in MySQL workbench. Because I like to visualize things, I find them quite useful when working with complex projects or structures because it makes it easier to see how every piece fits together to make one or several end solutions work.
Comments
Post a Comment