Difficulty: 6/10 · Time Commitment: 8/10 · Enjoyability: 7/10 · Mark: 90
I did COMP2511 (Object-Oriented Design and Programming) in Term 2 2022. The subject teaches object-oriented programming in Java and goes over many of the most common design patterns throughout the course. It is a really intense course compared to most others and has a major group work component which can be really challenging even with a great group. Overall, the subject consists of weekly labs, a solo assignment, a group assignment, and a final exam. Each of these components are really time consuming and although the majority of the content in this course is straightforward, the workload itself is high.
- This is the first course that introduces object-oriented programming and design patterns. Learning object-oriented programming is an integral skill to any software developer and learning it through a structured university course is a solid way to grasp the funamentals
- Because this course has a significant group work component, there is a need to navigate large codebases. This is a useful skill to carry forward and is easily learnt in this course compared to learning it for the first time during an internship or job.
- Lectures don’t well-equip students to do the labs and there are even specific labs that are recommended to be skipped (each student gets to skip a few labs without penalty) because they are extremely long (longer than entire assignments in other courses) and the content required to properly understand how to do them is not taught properly in the lectures.
- There is a mismatch between the lecturer for this course and the admin writing the lab exercises which means that the labs are often misaligned and don’t do their inherent job of consolidating course content.
COMP2511 is an extended version of everything on Refactoring Guru except it also goes into a lot of depth into the Java language itself and different conventions and styling standards that Java has that are important to know. When I did the course, the content on Java was actually taught really well and it’s a good idea to pay attention and take notes about those parts of the lectures. Unfortunately, the content on design patterns was taught extremely poorly and I would recommend reading through Refactoring Guru and using that as a cheatsheet while doing labs and assignments rather than rewatching lectures.
Lectures and Tutorials
Lectures and tutorials run independently of each other. What this means is that in a given week, the lecture content may be very different to the tutorlal and lab content. This means it’s a really good idea to both attend lectures and also pay attention during tutorials because there are many concepts that are taught first in the lectures but other content that is solely taught in tutorials before being assessed.
Additionally, when I did this course there were participation marks for tutorials so it was compulsory to attend them. These will probably still be around for at least the next few years but they are really easy to obtain if you simply attend class and participate in the activities and discussion even just a little.
Lectures in my term were not extremely important to understanding the content and it was much more effective to read from the lecture slides and only watch particular lectures corresponding to important topics or difficult things. I would recommend not falling behind on lectures and even looking ahead at future lecture slides because the course runs lectures and tutorials out of order and it can get overwhelming if you fall behind.
There is a solo assignment released in the first week of term for this course. The purpose of the assignment moreso than testing coding ability is about designing good code and choosing where to use interfaces and abstract classes. One thing I wish I had known before going into the assignment is that it is a good idea to plan out a proper UML diagram but be open to changing it when actually writing code as the spec changes or some new infmroation becomes apparent.
The assignment is split into different stages and they are exponentially harder than each other. Because of this, it is a good idea to start early but to write your code in a readable and modular way as the lectures sometimes only cover vital information a few days before the assignment is due, which may result in needing to rewrite huge parts of your code and completely redesign the UML diagram. I would recommend researching into the Liskov Substitution Principle and Law of Demeter before starting the assignment as we were told that they would be graded in the assignment and it’s much easier to abide by them before starting the code rather than a few days before its due.
When I did this course, there was a major group project consisting of 4-5 people over 3 milestones. I know that this has been changed in future terms to a smaller project and I cannot provide advice about that. Nonetheless, when I did COMP2511, I found the group project to be completely unreasonable for students. Even if you have a good group (my group was excellent) it still requires countless hours each milestone. The final milestone is also definitely the hardest and although it was only a week or two long, it took about double the time to complete as the first two milestones combined.
My advice for the project would be to prioritise completing it with a week to spare because the sheer volume of tasks to complete can become overwhelming as the due date gets closer. Additinoally, make sure that you have a good group. COMP1531 can be a nightmare without a good group but COMP2511 is without a doubt much worse if you don’t pick people that will carry their fair share.
Unlike COMP1531, the focus of this course is much less about good software engineering practices and although Git is used as a version control tool for each lab, assignment, and project, it is more of a tool for students than for marking - therefore it’s a good idea to implement good planning and documentation practices on Git but to only spend a reasonable amount of time as it isn’t marked too closely.
- Get a good group for the project. It can be super hard to do well and this course becomes increasingly unrealistic with its time commitment if you don’t have a good group. Try to form one before the course so that everyone can select the same tutorial.
- Start planning early but wait a few days before coding. When I did this course, there were always a lot of changes to the assignment and project spec + plenty of clarifications on ed. My recommendation is to start planning these out early. Specifically, try to draw out the UML and think about what design patterns and other considerations to use. However, leave the coding for a few days before starting simply so that you can view the clarifications on ed forum and don’t have to modify any spec changes that are made. This course does not reward starting early but it punishes tardiness so make sure you always leave enough time to finish everything.
- Use Refactoring Guru as much as possible. This website condenses the dense design patterns to a much simpler and easy-to-understand format. In some weeks, it’s even possible to skip the lectures and supplement your knowledge purely from this website.
- Learn about different OOP concepts before they are taught. Try to understand the Liskov Substitution Principle, Law of Demeter, and UML diagrams before they are taught in class because they are useful from week 1 onwards and save a lot of refactoring if you properly understand them.
- Always be open to refactoring your code. What I learnt from the project was that there will be many cases where it’s much simpler to refactor code and change the relationship between different objects rather than trying to work around a bad design. It saves a lot of time in the long run and helps you learn how to write better code.