The first assignment in this unit is where a lot of students meet an unfamiliar kind of feedback. The program compiles, the output matches, the automated tests pass, and the mark still comes back lower than expected.
The first assignment in this unit is where a lot of students meet an unfamiliar kind of feedback. The program compiles, the output matches, the automated tests pass, and the mark still comes back lower than expected. That is not an error in the marking. It is the unit doing what its outcomes say it will do, which is to assess the arrangement of your code as well as its behaviour, and to check that arrangement against a design you were given rather than one you invented.
Author: MAAS Editorial Team · Reviewed by a MAAS subject mentor
Last updated: 2026-08-23
Category: it-data
What the unit is, and the gate in front of it
Direct answer: INFO1113 Object-Oriented Programming is a 6-credit-point unit in the University of Sydney Faculty of Engineering, taught by the School of Computer Science, offered in Semester 1 and Semester 2 at Camperdown/Darlington, with a prerequisite of INFO1110, INFO1910 or ENGG1810.
Evidence: The published unit page opens by defining the subject: "Object-oriented (OO) programming is a technique that arranges code into classes, each encapsulating in one place related data and the operations on that data." It lists prohibitions against INFO1103, INFO1105 and INFO1905, and no assumed knowledge beyond the prerequisite.
Held together, the published record reads: code INFO1113, 6 credit points, University of Sydney, School of Computer Science, prerequisite INFO1110 or INFO1910 or ENGG1810, prohibitions INFO1103, INFO1105 and INFO1905, Java as the working language, 8 published learning outcomes.
The count of outcomes is the useful part of that list. Eight published outcomes give an unusually detailed map of what the unit examines, and reading LO1 through LO8 in order tells you where the marks sit. For comparison, INFO1112 in the same school publishes 13.
| Outcome group | What it covers | How many of the 8 |
|---|---|---|
| Core OO concepts and Java fluency | classes, instances, references, methods, control flow, I/O | 2 |
| Design comprehension | reading OO design documents and basic UML diagrams | 1 |
| Structuring a solution | choosing appropriate classes and data structures | 1 |
| Abstraction mechanisms | inheritance, polymorphism, abstract classes, interfaces | 1 |
| Verification | testing, exceptions, assertions, automated tests | 2 |
| Library fluency | common Java interfaces and collections | 1 |
Writing code that runs is necessary throughout and sufficient nowhere. Several outcomes involve producing code, including creating class structures and writing small examples, but they are phrased around the structure and the reasoning rather than around the output, and the remaining outcomes cover understanding a design, verifying behaviour and knowing the standard library.
Why does reading a design carry its own outcome?
Direct answer: Because in this unit you are frequently implementing a structure somebody else specified. One outcome is explicitly about reading object-oriented design documents and basic UML diagrams, which means the specification is an input you must follow, not a suggestion you may improve.
Substituting your own structure for the specified one is the single most expensive misunderstanding in the unit, and it catches capable students rather than weak ones. A student who reads a class diagram, sees a cleaner arrangement, and implements the cleaner arrangement has produced working code that does not match the specification. In an automated marking setup that often means missing methods, wrong signatures or wrong class names, and the tests cannot find what they are looking for.
Example: Given a diagram specifying an abstract class with 2 concrete subclasses, one student merged the subclasses into a single class with a type field, which is genuinely simpler and produces identical output. It also removed the exact structure the assignment existed to assess, since the point of the task was to demonstrate inheritance. The submission was correct as a program and empty as evidence.
The rule that follows is narrow and worth applying literally. When a specification names a class, a method or a signature, reproduce it exactly, including capitalisation. Design opinions belong in the parts the specification leaves open, and there are always such parts.
What does "appropriate class structure" mean when nothing is specified?
Direct answer: It means each class holds one responsibility and hides how it does its work, so that a change inside one class does not force changes across the rest of the program. That is the criterion markers apply when the specification leaves the structure to you.
Evidence: Parnas (1972) set out the criterion that still underlies this judgement, arguing that modules should be built around the decisions likely to change rather than around the steps of a process, so that each module hides a decision from the others. Translated into a first-year assignment, a class that exposes its internal list to the rest of the program has hidden nothing, and every other class becomes dependent on a choice you may later want to change.
Two practical tests fit inside a few minutes. The first is to describe each class in one sentence without using the word and. If you need and, the class is probably doing 2 jobs. The second is to ask what breaks if you change how a class stores its data internally. If the answer is anything outside that class, the encapsulation the unit description names is not actually there.
The description on the unit page is doing real work here. It says classes encapsulate related data and the operations on that data in one place. A class that is a bag of variables with the logic living elsewhere is not what that sentence describes, even if the program runs.
Why is inheritance the point where students stall?
Direct answer: Because inheritance looks like a way to avoid retyping code, and it is actually a claim about substitutability. When a subclass cannot stand in for its parent without surprising the code that uses it, the hierarchy is wrong even though it compiles.
Evidence: Liskov and Wing (1994) formalised the requirement, holding that a subtype must be usable anywhere the supertype is expected without changing the properties the calling code relies on. Liberman, Beeri and Ben-David Kolikant (2011), writing in ACM Transactions on Computing Education volume 11, studied 22 in-service computer science teachers moving from procedural programming to object-oriented programming, and traced their difficulties to the absence of a working mental model of inheritance and polymorphism rather than to syntax. Their participants were teachers rather than first-year students, so read the finding as being about the concept, not about your cohort.
MAAS mentors draw an inference from that, which is ours rather than the paper's: if the difficulty sits in the model rather than the syntax, then the questions that separate marks will rarely be write a subclass. They are closer to given this reference type and this object type, which method executes, which is a question about dynamic dispatch rather than about typing skill.
A habit that helps: whenever you write an override, say out loud what promise the parent method made, and check that your version still keeps it. If your override throws where the parent returned, or returns nothing where the parent guaranteed a value, you have broken substitutability, and that is a design defect a test may not catch.
What are automated tests actually rewarding?
Direct answer: Automated tests reward interfaces that behave exactly as specified, including in the cases nobody wants. Two of the 8 published outcomes cover testing, exceptions and assertions, so how your program behaves when something goes wrong is assessed content rather than defensive extra work you do for your own comfort.
Students write for the case where the input is valid, because that is the case the example in the brief shows. The marks then hinge on what happens with an empty collection, a null reference, an index out of range, or a file that does not exist. An exception thrown deliberately, with a message that names the problem, is a correct answer. A program that crashes with a stack trace, or silently returns a wrong value, is not.
Write your own tests before you write the method rather than after. The list is short and mostly the same each time: the ordinary case, the empty case, the single-element case, the boundary at each end, and the invalid input. Five cases per method is a reasonable habit at this level, and it also forces you to decide what the method promises before you decide how it works.
What is different for students who learned programming in another language?
Direct answer: The obstacle is usually Java's explicitness rather than the concepts. Static typing, checked exceptions and the compiler's insistence on declarations make Java say out loud what other languages leave implicit, and that verbosity reads as difficulty when it is really disclosure.
Two adjustments carry most of the benefit. The first is to read compiler errors as information rather than as noise. A Java compiler error usually names the file, the line, the expected type and the found type, which is a more complete diagnosis than a runtime failure gives you. Students who came from a language where problems surface at runtime often skim these messages, which discards the most useful feedback the tools produce.
The second is vocabulary. Much of the assessment is phrased in specific terms, including reference, instance, abstract, interface, override, overload and polymorphism. Overload and override differ by one concept and by several marks. Keep a short glossary in your own words, since the exam questions are written in these words and a question misread is a question lost.
Where does outside help stop being useful on assessed code?
On an assessed programming task the boundary is sharper than usual, and a mentor who writes any of your code has taken the assessment away from you. What a session does look like is reading a specification together before you start, sketching which classes the specification actually requires, and afterwards walking through your own design against the questions above, particularly whether each class holds one responsibility and whether your overrides keep the parent's promise.
If you are on the tutoring pathway, the most productive material is a marked assignment plus the specification it was written against. The distance between the two is where the lost marks usually are, and it is a conversation about design rather than about syntax.
Frequently asked questions
Which units let me in?
The published prerequisite is INFO1110 or INFO1910 or ENGG1810. There is no assumed knowledge beyond that, and entry rules are reviewed between years, so check the page for your own year.
Which language is it taught in?
Java. The published outcomes name Java explicitly, including its common interfaces and collections.
Can I take it if I have done INFO1103 or INFO1105?
No. Those are listed as prohibitions, along with INFO1905. Confirm the prohibition list for your year before planning your enrolment.
If the tests pass, is the assignment finished?
Not necessarily. Passing tests demonstrate behaviour, and several outcomes are about structure, abstraction and design comprehension, which tests do not measure.
Should I improve a design the specification gives me?
No. Implement the specified structure exactly, including names and signatures. Save your design judgement for the parts left open, and note your reasoning in comments if the task allows it.
Related reading
- INFO1110: introduction to programming
- INFO3315: human computer interaction
- Tutoring from MAAS mentors
Ask a MAAS mentor about your unit
References
Liberman, N., Beeri, C., & Ben-David Kolikant, Y. (2011). Difficulties in learning inheritance and polymorphism. ACM Transactions on Computing Education, 11(1), Article 4. https://doi.org/10.1145/1921607.1921611
Liskov, B. H., & Wing, J. M. (1994). A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems, 16(6), 1811–1841. https://doi.org/10.1145/197320.197383
Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623