Sunday Serious Series: A1 Report Part 1

There will be two posts (hopefully) this week, since I finally gathered enough inertia to write about my first assignment (A1) in CSC148!!! This part will focus on how I feel about the assignment retrospectively, and in the second part, which will come when result is actually released, I will talk about the the feedback I get, etc.

An analysis of A1 (See http://www.cdf.toronto.edu/~heap/148/W14/Assignments/A1/a1.pdf)

The main theme of A1 is the 4-peg variant of Tower of Hanoi. It takes me 2 all-nighters to finish (no no I didn't do it right before the deadline. I just couldn't resist to finish it in one go.) The work that was to be done can be loosely divided into three main parts.

Part 1

The part includes Step 1 to Step 4, and is the implementation of a class to represent the game itself. In this part I think the most important and also the hardest task is to understand the underlying design principle - which I would say is Separation of Concern. As in this page on separation of concern on Wikipedia, under this principle a computer program is seen to be composed of different sections, each section dealing with a separated concern, which is information that interacts with the codes. The ConsoleController class will deal with user input, while the TOAHModel and Cheese classes is responsible of modelling of the game. I myself think that OOP is highly related to this design philosophy - the implementation the Cheese class not only make it object-oriented, but also separates the rules of moving cheese (in TOAHModel) from Cheeses itself. Doing this part can be a nightmare if the principle is not fully appreciated - it will basically be a blind guess on how should codes be written to work with the give starter code.

Part 2

This part is just Step 5 and Step 6, but it is the essence of this assignment - solving the  4-peg variant of Tower of Hanoi. The solution is one of the most complicated recursion I have ever written, since it acts on mutable objects and extreme care is needed to keep everything in track. My implementation is slightly clumsy, not that it didn't give back the expected result, but a lot of computation is redundant. This and the method I learnt to resolve the redundancy will be discussed in greater detail in the next post, which will focus on recursion.

Part 3 (Bonus)

This is probably the easiest part, the only difficulty is picking a standardized key for sorting lists containing cheese objects. Not really requiring specific knowledge.

Overall I don't find the assignment particularly challenging in terms of new concept, but still I think a lot of confusion can be avoided if the instructions given are more clear - after all this assignment does not involves much freedom in design and the corresponding constraints should be easily understood. I have also looked into the second assignment, which involves many more design and lots of freedom is given. Perhaps I will give a intermittent report on my progress - it seems hard.

Sunday Serious Series: Object-oriented Programming Rebooted

Two weeks after the first post.

A lot have changed, and one of them is my understanding on OOP after finishing the first assignment (yay!), and I find my first post is basically explaining something abstract with some other abstract concepts. Which is bad, real bad. So I guess I am rewriting that part, but I will leave the first post there as a reference (to how little I knew). See my good friend http://thefabricofourpeople.blogspot.ca on why I think so XD

What is Object-oriented Programming (OOP)?

OOP is a programming paradigm (style), where the idea of treating everything as objects - from integers and Boolean (which is interestingly a sub-class of integers, will explain what that means below) to functions and exceptions, they are all objects. User-defined classes  can be created if what you exactly need is not available. As mentioned in the first post, being object-oriented can provide insights into the actual relations in between different objects, and it is very intuitive (to think about, at least) since this is often how we see things in reality. Of course, this is a kind of formality, and its implementation and support is different for different languages, so the exact details can vary.

Formality? Does that mean inefficiency?

Yes and no. When I started using OOP in the first assignment, the first step in the instruction is to 'Read and understand the Cheese class.' and all the class specifies is attribute that is an integer, and a method to compare cheese base on that integer. All the work done by this Cheese class can be done without creating a new class. The value of having an object representing cheese is not there. Instead, it allows us to think about the cheeses and not the integer. This really outweighs the cost of the additional code needed , since when I am trying to work on later parts of the assignment (solving a 4-stool variant of Tower of Hanoi recursively), I can think in terms of the pieces that I need to move, and then code with the same thing. I don't need to mentally convert it back to some specific integers when I write the code, and in larger program there may just be too much such mental work to be done and errors are creeping in. So similar to many other kind of formality, it allows us to pay a small price and avoid a lot of trouble. It should be noted that it does not magically do the work for us, nor it is capable of doing something that the language itself could not accomplish.

Okay, does OOP has any other drawbacks then?

In my opinion, yes - some small ones do exist. Creating an extra layer of formality can lead to confusion when different people do it differently. To avoid this extra documentation and communication are often necessary, which is again work to be done - this also happens in the programming language level. Another possible problem is that while the formality makes it easier to think within its framework, it sometimes affect the ability to think outside of it. I don't know how big this problem is - this is purely theoretical, but I guess awareness is needed to avoid being constrained by OOP.

I guess this should showcase OOP a bit better than the previous post XD I will be posting shortly to talk about the assignment more specifically.