CSC148 Term Test 1: To Do List

Last night I had this wonderful idea. The first term test is coming up soon, so why not blog a bit about it? Anyways, for your convenience, I've made a long and messy list of the concepts we'll be covering on this term test. I've also marked the concepts I still need to cover, so I can use it as a study guide during these next few... well... hours...


COURSE NOTES CHAPTER 1:

-Objects (information and behavior)
-ADT
-Implementation vs. Semantics
-Stacks (stores items, remove top, add to top, check if empty)
-expose interface
-interface
-clients
-docstring
-inheritence
-extension
-concretizing ADT
-classes
-operations and attributes of classes
-class instance
-initializing an instance
-Magic methods
-__eq__ (equivalence NOT identity)
-__init__
-equivolence vs identity
-__repr__
-__str__ (is set to __repr__ as default)
-Exception class
-privacy and property
-inheritence
-composition vs non composition
-subclass
-override vs extend
-inheritance (allows to override or extend)
-self
-__add__
-class exception
-raise
-try/except


LECTURE MATERIAL
-object oriented design
-help()
-client code
-interface
-public interface
-public
-magic methods __init__, __str__, __eq__
-overriding
-class object
-__repr__
-property
-eval()
-ADT
-stack ADT
-uses of stacks
-doctest
-parent class
-child class
-canonical use of inheritence
-extend vs override
-list comprehensions
-merge sort
-recursion
-recursive function
-tracing recursion
-measure of problem size (list depth, etc)
-formally thinking recursively

TUTORIAL MATERIALS
-object oriented design
-recipe for designing functions, methods, classes, etc
-tracing recursion
-writing recursive code
-pep8
-reading/writing to files


...Yes, I still need to cover pep8 and the CSC108 design recipe. I know how to use it to design functions, but I'm still not sure exactly how I should design methods, classes, etc, using those core principles. Should I worry about corner cases as much? Should I include anything in the class doc-string other than a core description or what the class represents and what public attributes are contained within it? Should it also list the public behaviors (methods) in the class? And speaking of privacy, I still cant think of any redundant, non-gimmicky ways to use it. At this state, I feel that it just makes our codes unnecessarily fatter and thus harder to read.

Well, that's it for now. Time to study.