This week in class, we covered linked lists. These can be thought of in two possible structures: (1) lists with an item and sublist, or (2) objects with a value and reference to similar objects. Our focus was on the latter view. As with stacks, we have access only to certain regions of our linked list - the front, back, and size. In order to add an item to the linked list, we need to make a reference from the now-second-last node to the now-last-node. It is interesting to think about the steps that need to be made to access information in the interior nodes. We can walk along the nodes starting from the front, seeing where each node's reference leads us until we reach our desired node or value, or lack thereof. Not too sure whether this topic will be on our upcoming test, but I will practice it anyway as I am sure it will come in useful at some point in the course.
I have been reading up on other SLOGS, and stumbled upon a post that made me wonder how well I really understood object oriented programming and abstract data types (ADTs) (http://thecodingdiaries.blogspot.ca/2015/02/week-9.html). It is mentioned here that abstract data types are "hazy concepts", a statement that I agree with entirely. An especially smart thought was that ADTs are general categories that do not contain specific information but rather contain groups that follow certain rules on how their data can be manipulated. Objects are instances of ADTs. Also mentioned in the post was what happens when trying to find the type of various types of ADTs and instances of classes or objects - I have never before analyzed this! In the future, I will always stop to consider how my coding relates to ADTs, how this affects the functionality of my code, and what it really means to be an abstract data type.
Thanks for the feature and the comment. In all of my analysis I failed to consider the difference between data types and abstract data types and the "hiding of information" which is obviously essential to ADTs.
ReplyDeleteI think of ADT's more in terms of having many possibilities in terms of how it can be instantiated, rather than that they are hazy. To say something is hazy seems to insinuate that the property of being abstract is somehow stored in the object itself. In my opinion (and there really isn't much of a right answer on this), to be abstract is really more of a relation between the sort of "broad class", and all its possible instantiations/realizations. Which certainly makes sense of some of our intuitive notions of what it means to be abstract (for example, an integer is a type of number. a number is very abstract because it can refer to so many things. If you wanted to fish out an example of a number, you could pick out the square root of pi, or the natural number 5, or even a rock, which could represent 1).
ReplyDelete