OOP

    Object-oriented programming (OOP) is a programming language structure that is based on the concept of 'objects', which are data structures that contain all sorts of wonderful information. Different objects can and will have different data (also known as attributes) and different procedures (also known as methods) to do certain tasks.

    Now you might be thinking, "How do we create an object?". Well in Python, objects are instances of classes. So in other words, if you want to create an object, all you have to do is create a class! As we've learned from before, when we create a class, we also need to create the __init__, __str__, __repr__, and __eq__ functions. BUT WAIT!!! These aren't functions! When we write functions inside of a class they are actually called 'methods'.

    I guess the best thing about objects is that it can actually save you time and energy from rewriting code. For example, you can create a subclass for the built-in String class and it will inherit ALL the methods that the String class has! Don't see how that saves time? Go ahead and create a class and try to write ALL the SAME methods that the String class has.

    Just by doing that, MyStringClass has now inherited ALL the methods that the built-in String class has. Don't believe me? Go ahead and create a class like my MyStringClass and use isinstance(MyStringClass, str). It should return True since MyStringClass is a subclass of String.

Recursion

    This past week we started to learn the basics of recursion. Although I have kind of learned recursion before, I was never really able to truly understand it. All I knew about recursion was that the function would actually call itself over and over again until it reaches a condition that makes it stop... Now that I think about it... it's kind of like inception, but instead of going deeper and deeper into dreams you're going in deeper and deeper into the layers of code every time the function calls itself.

    The work we have done so far with recursion is just tracing the code when a recursive function is called with a list and we trace the code with nested lists as well to get the final result. I guess the biggest problem I had with tracing recursion was knowing when to replace calls I've already traced with their value. So with that problem, instead of tracing something like sum_list([[1, 2, 3], [4, 5], ,8]) in 2-3 lines, I would end up tracing each call of the function so I end up with 6 or 7 lines which most of them I have already traced before.

    After doing the lab on recursion, I feel that I have a much better understanding of it and I can trace simple recursive functions without much trouble. But one of the exercises on the lab was to write a recursive function and since we never went over how to actually write a recursive function during the lectures, I had quite a bit of trouble with that. After working on it for a while, my lab partner and I were finally able to write a recursive function. Since the lab ended of with a bit of practice on writing recursive functions, I guess this weeks lectures will teach us how to actually write recursive functions!

First Impressions

    These past few weeks we have mainly worked on class design. We went through how there can be abstract classes that don't really have to do much other than initializing and raising 'NotImplementedErrors' and more specific classes that can inherit methods from the abstract class and do more things with them! I guess a good example of the use of abstract and specific classes would be assignment 1, where we have our abstract game state and our more specific game state for the subtract square game. I guess assignment 1 has really opened my eyes and showed me why the more abstract your class can be, the better it is. I only say that because we've been told that assignment 2 and 3 is going to use the abstract game state and build on to it, so I guess it's a good thing it's abstract and not specific to any game at all or else I'd have to rewrite code... While I'm on the topic of assignment 1... I feel like my partner and I wasted quite a fair amount of time rewriting and modifying our code because we didn't really know what to put in our classes when we first started off. But when we finally figured out how we wanted to design our classes and implement subtract square, the assignment went pretty smoothly from that point on and I feel that we were able to get our abstract classes and our game view class to be as generic as possible (which is good!).