CSC 203 Project-based Object-oriented Programming and Design
Contents
- Info and links
- Learning objectives
- Class communication and getting help
- Attendance policy
- Assignments
- Classroom climate and conduct
- Course schedule
- Acknowledgement
Welcome!
This course is all about software design. We will use object-oriented programming as a vehicle to study software design principles like separation of concerns, coupling and cohesion, and encapsulation. We will learn and use the Java programming language in this course, though the software design lessons learned are meant to be transferable to other languages and programming paradigms as well.
Here’s the description in the course catalogue:
Object-oriented programming and design with applications to project construction. Introduction to class design, interfaces, inheritance, generics, exceptions, streams, and testing. 3 lectures, 1 laboratory. Prerequisite: CPE/CSC 202 with a grade of C– or better or consent of instructor.
Info and links
- Instructor: Ayaan M. Kazerouni
- Email: ayaank@calpoly.edu
- Office hours: See my website
- Class Canvas
- EdStem forum (see the invite link in Canvas)
- Course schedule (Check this frequently!)
- CSSE tutoring lab: Your fellow students offer free tutoring for various introductory CS courses, including CPE/CSC 203.
Learning objectives
By the end of the quarter, we aim for you to be able to:
- Explain key object‐oriented concepts including: classes, objects, methods, instantiation, invocation, interaction between objects, composition, encapsulation, and use of class libraries.
- Use object‐oriented concepts and design to implement moderately sophisticated “large” programs.
- Describe the philosophy and mechanics of interfaces, including abstraction, separation between specification and implementation, subtypes and type casting, polymorphism, interface hierarchies, and implementation of multiple interfaces.
- Create a unit test plan for a set of methods in a class.
- Use inheritance in the implementation of program components such as in the application of a refactoring process to an existing software implementation to improve some aspect of its design.
- Articulate design principles including separation of concerns, information hiding, coupling and cohesion, and encapsulation.
- Apply class design principles to the development of a design document for a moderately sophisticated “large” program.
- Implement programs that use generic types.
Class communication and getting help
We will use EdStem for class-related Q&A. See the invite link in Canvas.
Please ask all course-related questions in EdStem, unless you are sending me documents or files of some kind, or asking about things that apply only to you, like assignment extensions.
Some benefits of using EdStem are:
- You can answer each other’s questions or participate in discussions.
- The forum will be a searchable index of questions. This can save you a ton of time when you’re working on something and need a question answered. It will also help me avoid answering the same question multiple times.
- You can post questions anonymously.
You’re also welcome to stop by my office whenever you have questions, or just to chat about the course. I encourage it! Try problems yourself before coming to me—you will learn a lot from trying and re-trying with alternate strategies—but don’t stay stuck for too long. While I won’t sit and debug your code with you, I can give help and hints for where to look. If you can’t make office hours, contact me and we can schedule an appointment for another time.
Attendance policy
There is no explicit attendance policy for this class. However,
- There will occasionally be graded activities in class that you must be present to complete.
- There is no textbook that we’ll follow, nor are there usually slides. I’ll upload code examples I discuss in class, but studying from them will be difficult without the surrounding context you would receive by attending class.
- My teaching is interactive; I rely on input from students to drive class sessions, particularly while live-coding. If you’re not present, you’re relying on other students asking the questions you might want to ask.
Anything I say in class is fair game for quizzes (within reason and unless specified otherwise).
All this adds up to: I strongly recommend that you attend every class session!
If you’re unable to attend class for some reason, drop me a note to let me know. This way if there’s an activity that class period, I can give you an opportunity to make it up.
Assignments
Frequency | Portion of the final grade |
---|---|
6–8 lab exercises | 20% (2-3% each) |
4 projects | 40% (11% + 11% + 11% + 7%) |
6–7 quizzes | 15% (3–4% each) |
1 final exam | 15% |
Participation | 10% |
Total | 100% |
Please see each program description for grading/rubric details.
At the end of the course, I will round UP your final numerical score and turn that into a letter grade using the following scale:
- A >= 93
- A– >= 90
- B+ >= 87
- B >= 83
- B– >= 80
- C+ >= 77
- C >= 73
- C– >= 70
- D+ >= 67
- D >= 63
- D– >= 60
- F < 60
I won’t curve grades, aside from a few very specific cases. Please don’t ask me if I’ll curve your grade at the end of the quarter.
- Source code for all programming assignments will use the most recent Java version.
- For all labs and projects, we will use IntelliJ IDEA as the editor, and GitHub classroom for downloading starter files and submitting solutions.
- Please create a GitHub account by the first day of class. If your GitHub username does not include your name, please add your name to your profile—I’ll need to know to whom each account belongs.
Labs
There’ll be a lab assignment roughly each week. These are meant for practice with the concepts we talk about in lecture. The goal here is to familiarise you with material necessary for your projects and to help you do well on the quizzes.
The three hours of scheduled lab time each week is the primary time I’ll be available for questions and assistance—make good use of this time! You are expected to work on the lab exercises during your scheduled lab time plus as much additional time as necessary to complete them. You ARE allowed to discuss labs with classmates, but you must turn in your own work.
You may also demonstrate your lab to myself or the student assistant before your final submission—this will allow you to get at least one round of feedback before grading takes place.
Late policy
Labs may be turned in 1 day late for up to 70% credit. It’s your responsibility to make sure the staff know when you are doing this—without prior communication, we will not know to look for late lab submissions.
Labs will be graded against test cases, in-lab demonstrations, or both.
Projects
There will be 4 programming projects throughout the quarter. These are meant for assessment of your ability to apply to the concepts we talk about in lecture and practice in labs.
All projects will require analysis, design, implementation, testing, and documentation. Turning in a fully functional project is not a guarantee of a perfect score—remember, the goal of this course is to learn about software design, and so each project rubric will involve a significant design component.
Late policy
You are allowed THREE late days, to be used as you wish on any of the FIRST THREE projects (not on labs and not on Project 4).
If you plan to use a late day, you must email me ahead of time (i.e., before the active project’s deadline) telling me how many late days you plan to use. This must happen over email because we will need to remember that information at grading time.
The reason for this policy is that I recognise life as a college student is often stressful and I don’t know all of the situations you each are experiencing—your mental and physical health is a priority. In addition, if the policy was “no late work”, some students may feel more entitled to ask for extensions in an emergency than others—the extension is meant to be an equaliser.
A couple of things to note regarding this extension:
- Do not use the late days lightly—save it for when you are managing several colliding deadlines or lose days because of illness.
- Do not lose track of when you use late days—it’s your responsibility to make sure you don’t go beyond your allotted extensions.
- The last three projects will build on each other—you do not want to use late days on those unless absolutely necessary. The class is intentionally paced—if you use this policy as a procrastination tool, your work will pile up.
Quizzes
We’ll have weekly quizzes, taken on Wednesdays at the start of lab. These are meant to assess your understanding of the concepts we talk about in class. You must be present in class to take the quiz. If you are not present in class, your score for that quiz is automatically a 0.
If you have an unavoidable reason why you cannot make it to class on a quiz day, please talk to me about it. If you miss class for some unforeseeable reason or emergency, please talk to me as and when you are able to after a quiz. I’m usually willing to do make-up quizzes if they are missed for legitimate reasons.
Quizzes will be cumulative since programming knowledge tends to build on itself. But they will mostly focus on material from the previous week.
Quizzes will be open-note. This means you can use your notes or material that I have provided to help you take the quiz. However, you cannot use other resources like Google, StackOverflow, or large language models to help you take the quizzes.
I won’t ask questions that require you to memorise obscure facts, and on the rare occasions I ask you to write code in a quiz, I will be lenient for things like syntax issues.
Quizzes will have time limits. These will be somewhat tight time limits. This means you cannot rely purely on the open notes to take the quiz.
Final exam
There will be a written final exam during finals week. The exam’s goal is, naturally, assessment. The exam will be have questions similar to what you have seen on the quizzes, so studying the quizzes is a good way to study for the final.
The time and place for the final exam are still being decided, since it will be a common final exam taken at the same time by all sections of CSC 203.
This means that our course will NOT use the Registrar-allocated final exam time for our lecture time. We have requested a common final exam slot and will be allocated one by the Registrar in the coming weeks. I will update the schedule and make an announcement when the time is finalised.
Classroom climate and conduct
Academic honesty
Although I encourage you to have lively discussions with one another, all work you hand in must be your own work, unless otherwise specified. Programs will be compared using software that can reliably detect similarities in source code.
Though you are encouraged to seek help in tutoring and from the TA and instructor, do not look at classmates’ code or show your code to classmates. Unless explicitly allowed to do so, do not discuss specific implementation of your code. If your program or parts of your program are plagiarized from another student or an unapproved source, you will face severe penalties, to the possible extent of failing the course and having a letter put in your file with Cal Poly Judicial Affairs.
This includes students who copied and students who were copied from—you are responsible for the privacy of your source code.
Use of large-language models like ChatGPT
Large-language models (LLMs) and similar tools have the potential to radically change the way in humans work. I understand the value-added in using ChatGPT and its ilk to help learn and study. But these tools should be used carefully, and never in a way that undermines the spirit of expending genuine mental energy to understand material and to complete programming assignments.
I have used it myself for quick routine tasks — however, I need to correct its output frequently, often in subtle but impactful ways. It can be challenging for newcomers to a programming language—such as, I expect, yourselves—to tell when ChatGPT’s output requires modifications or wholesale revisions. One might say that an indirect goal of a class like this is to prepare you with skills that will allow you to be able to use AI code synthesisers effectively in the workplace.
As such, I am imposing the following rules with respect to its usage in CSC 203 (I say “ChatGPT” below, but these rules apply to any similar AI-based tools):
- You MAY use it to help study and understand material from class.
- You MAY use it on lab assignments, provided that you provide the prompt you used (or a description of your interaction) in a comment and are honest about your usage of it. Talk to me if you are not sure how to write this attribution.
- You MAY NOT use ChatGPT during quizzes or the final exam.
- You MAY NOT submit any code generated by ChatGPT for programming projects.
- Because you may not submit any ChatGPT-generated code in project submissions, it is specifically not acceptable to say that you submitted the same code as another student because it was generated by ChatGPT. Duplicate submissions, even those due to identical outputs of ChatGPT, will be considered academic integrity violations, and subject to the treatments above.
Class conduct
Our classroom and lab are to be places of learning and inclusion. Students of all ages, abilities, background, race, sexual orientations, beliefs, religious affiliations, gender identities, and origins are to be treated with dignity and respect as contributors to our scholarly environment.
- We are not code snobs. We do not assume knowledge or imply there are things that somebody should know.
- After our work is complete, we prioritise the education of others and actively offer to help, explain, debug, etc. in order to support one another’s learning. We do not share our working solution, but explain the logic/thinking behind our solution and help others recognise errors in their implementation when invited to do so.
- We consistently make the effort to recognise and validate multiple types of contributions to a positive classroom environment.
Course schedule
Here is our intended course schedule. If things change as we go, I will update this page. Assignments and quizzes will appear in Canvas with deadlines. If deadlines listed here conflict with deadlines in Canvas, the Canvas deadlines should take precedence.
WEEK | DAY | TOPIC AND NOTES | ASSIGNMENTS |
---|---|---|---|
1 | Wednesday, 4/2 | Introduction | Introduce yourself in EdStem You’ll need to join the forum first, see the invite link in Canvas. Create a GitHub account Download and setup IntelliJ IDEA and Java Lab 0 (Intro to Java) |
Friday, 4/4 | Data types, arithmetic, type-casting | Lab 0 Lab 1 (Loops and lists) |
|
2 | Monday, 4/7 | Classes, objects, lists, maps | |
Wednesday, 4/9 | Procedural and object-oriented programs | Quiz taken in lab Project 1 |
|
Friday, 4/11 | Instance members and static members | Lab 1 | |
3 | Monday, 4/14 | Method dispatch (overloading and overriding) | Lab 2 (Classes, objects, and methods) |
Wednesday, 4/16 | A class design process | Quiz taken in lab | |
Friday, 4/18 | Schedule wiggle room | ||
4 | Monday, 4/21 | Interfaces (part 1) | Lab 2 Lab 3 (Interfaces) |
Wednesday, 4/23 | Interfaces (part 2) | Quiz taken in lab Project 1 Project 2 |
|
Friday, 4/25 | Interfaces (part 3) | ||
5 | Monday, 4/28 | Abstract classes | Lab 3 Lab 4 (Inheritance, equality, hashCode) |
Wednesday, 4/30 | Inheritance and equality | Quiz taken in lab | |
Friday, 5/2 | equals |
||
6 | Monday, 5/5 | hashcode |
Lab 4 |
Wednesday, 5/7 | Comparables and comparators | Quiz taken in lab | |
Friday, 5/9 | Comparators, lambdas, and method references | Project 2 Lab 5 (Comparators, lambdas, and streams) |
|
7 | Monday, 5/12 | Lambdas and functional interfaces | Project 3 |
Wednesday, 5/14 | Streams | Quiz taken in lab | |
Friday, 5/16 | Binary trees (OpenDSA Chapter ⇗) and Depth-first search and breadth-first search (OpenDSA Chapter ⇗) | Lab 5 Lab 6 (Depth-first search) |
|
8 | Monday, 5/19 | A-star search | |
Wednesday, 5/21 | More on A-star search | Quiz taken in lab | |
Friday, 5/23 | Testing A-star search | ||
9 | Tuesday, 5/27 | Project 4 discussion Final exam review |
Project 3 Project 4 |
Wednesday, 5/28 | Exceptions and exception handling | Lab 6 Lab 7 (Exception handling) |
|
Friday, 5/30 | Exceptions and exception handling | ||
10 | Monday, 6/2 | ||
Wednesday, 6/4 | Final exam review | Lab 7 | |
Friday, 6/6 | Schedule wiggle room | Project 4 | |
11 | FINALS WEEK | DATE TO BE ANNOUNCED |
Acknowledgement
I inherited a version of this course in 2020, and bits and pieces have changed over the years. But the core content is as it was, so I am grateful to Julie Workman, Paul Hatalsky, Zoë Wood, and Aaron Keen for their efforts in creating this course.