This first year is largely characterized by gaining a solid foundation in programming and the nature of the science. This would be a curriculum encompassing techniques (certainly not language specific), computational thought, and building confidence in a world that is foreign to most of us even though we utilize computers all the time. This was accomplished astoundingly well in the prerequisite course in which experiential learning was paramount. Before a larger assignment or test, concepts were thrown at you in parts combined with small problems all revealing new information about it upon discovery of the solution.
This is what introductory CS should be about, grasping these ideas through self discovery (we've got to play at this stage of infancy!), and then drilling them until they're second nature. I feel that deeper discussion of concepts is a great exercise for those who already have this foundation and can extrapolate from the material even when removed from the computing environment. The latter notion is a skill derived from a great deal of experience that many of us in CSC148 do not yet boast.
So, to refrain from proliferating excuses and complaints about this assignment I will attempt it. Though I cannot promise that details won't be sparse.
Object Oriented Programming is a readily accessible aspect of python that, as has been imposed upon me in lecture, is much more so than other languages. Implementing classes and their associated methods whether they're completely new or they inherit from another class are far from tedious. All classes though technically inherit from the grandfather class the "object", for which the most basic methods have been defined in a very general way. Not much else has been elucidated with respect to the "object". Most of our early discussion has been about formatting classes such that the methods and attributes can be organized in an intelligible way. It is possible to augment the behaviour of classes whenever, but such things are highly discouraged as it can be difficult for other programmers to ascertain as to how the class works and how it relates to other objects.
Finally when designing new classes, writing about the abstract data type is a great way of collecting your thoughts and to avoid building on a class in an unintelligible way. No discussion of implementation or the type's relationship to the digital world is made, only that the type is based on a real world device or entity that can be used to interact with information or other entities. It is this interaction that is the subject of a brainstorm. What actions (methods) can the type perform? These different actions are to be so clear that any competent programmer in any language could understand what you're describing and be able to implement it in their language/space with little to no ambiguity.
No comments:
Post a Comment