Bài tập lớn đầu tiên của môn này là chỗ nhiều bạn lần đầu gặp một kiểu nhận xét lạ. Chương trình biên dịch được, kết quả in ra khớp, bộ kiểm thử tự động chạy qua hết, vậy mà điểm trả về vẫn thấp hơn mong đợi.
Bài tập lớn đầu tiên của môn này là chỗ nhiều bạn lần đầu gặp một kiểu nhận xét lạ. Chương trình biên dịch được, kết quả in ra khớp, bộ kiểm thử tự động chạy qua hết, vậy mà điểm trả về vẫn thấp hơn mong đợi. Đó không phải lỗi của người chấm. Đó là môn học đang làm đúng thứ chuẩn đầu ra của nó đã ghi, tức là chấm cả cách bạn sắp xếp mã nguồn chứ không chỉ chấm hành vi của nó, và đối chiếu cách sắp xếp ấy với một bản thiết kế bạn được giao chứ không phải bản bạn tự nghĩ ra.
Tác giả: Ban biên tập MAAS · Cố vấn chuyên môn MAAS thẩm định
Cập nhật: 23/08/2026
Chuyên mục: it-data
Môn này là gì, và cái cổng đứng trước nó
Trả lời trực tiếp: INFO1113 Object-Oriented Programming là môn 6 credit points thuộc Faculty of Engineering của University of Sydney, do School of Computer Science phụ trách, dạy ở học kỳ 1 và học kỳ 2 năm 2026 tại Camperdown/Darlington, Sydney, với môn tiên quyết là INFO1110 hoặc INFO1910 hoặc ENGG1810.
Bằng chứng: Trang môn học chính thức mở đầu bằng định nghĩa: "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." Trang cũng ghi các môn cấm học song song là INFO1103, INFO1105 và INFO1905, và không yêu cầu kiến thức giả định nào ngoài môn tiên quyết.
Gom lại, hồ sơ công bố của môn đọc như sau: mã INFO1113, 6 credit points, University of Sydney, School of Computer Science, tiên quyết INFO1110 hoặc INFO1910 hoặc ENGG1810, cấm song song INFO1103, INFO1105 và INFO1905, ngôn ngữ làm việc là Java, 8 chuẩn đầu ra công bố.
Ba nguồn tham khảo chính của bài này là Parnas (1972) trên Communications of the ACM, Liskov và Wing (1994) trên ACM Transactions on Programming Languages and Systems, và Liberman cùng cộng sự (2011) trên ACM Transactions on Computing Education. Số lượng chuẩn đầu ra mới là phần đáng chú ý trong danh sách đó. Tám chuẩn đầu ra công bố cho một bản đồ chi tiết bất thường về thứ môn học kiểm tra, và đọc lần lượt cả 8 sẽ thấy điểm nằm ở đâu.
| Nhóm chuẩn đầu ra | Nội dung | Chiếm mấy trong 8 |
|---|---|---|
| Khái niệm OO cốt lõi và độ thạo Java | lớp, thể hiện, tham chiếu, phương thức, luồng điều khiển, nhập xuất | 2 |
| Đọc hiểu thiết kế | đọc tài liệu thiết kế hướng đối tượng và sơ đồ UML cơ bản | 1 |
| Dựng cấu trúc lời giải | chọn lớp và cấu trúc dữ liệu phù hợp | 1 |
| Cơ chế trừu tượng | kế thừa, đa hình, lớp trừu tượng, giao diện | 1 |
| Kiểm chứng | kiểm thử, ngoại lệ, khẳng định, kiểm thử tự động | 2 |
| Độ thạo thư viện | các giao diện và tập hợp thông dụng của Java | 1 |
Viết được mã chạy là điều kiện cần ở khắp nơi và không đủ ở bất cứ đâu. Nhiều chuẩn có phần tạo ra mã, gồm dựng cấu trúc lớp và viết những ví dụ nhỏ, nhưng chúng được diễn đạt quanh CẤU TRÚC và lập luận chứ không quanh kết quả in ra, còn các chuẩn còn lại nói về hiểu một bản thiết kế, kiểm chứng hành vi và biết thư viện chuẩn.
Vì sao việc đọc thiết kế lại có hẳn một chuẩn đầu ra riêng?
Trả lời trực tiếp: Vì trong môn này bạn thường phải hiện thực hoá một cấu trúc do người khác đặc tả. Một chuẩn đầu ra nói thẳng về việc đọc tài liệu thiết kế hướng đối tượng và sơ đồ UML cơ bản, nghĩa là bản đặc tả là đầu vào bạn phải tuân theo, không phải gợi ý bạn được quyền cải tiến.
Trong 8 chuẩn đầu ra, đây là chuẩn duy nhất không nói về việc bạn tạo ra thứ gì. Đây là hiểu lầm tốn kém nhất của môn, và nó thường vướng vào những bạn giỏi chứ không vướng vào những bạn yếu. Một bạn đọc sơ đồ lớp, thấy có cách sắp xếp gọn hơn, rồi hiện thực hoá theo cách gọn hơn ấy, sẽ tạo ra mã chạy được nhưng không khớp đặc tả. Trong hệ chấm tự động, điều đó thường có nghĩa là thiếu phương thức, sai chữ ký hàm hoặc sai tên lớp, và bộ kiểm thử không tìm thấy thứ nó cần tìm.
Ví dụ: Được giao sơ đồ đặc tả một lớp trừu tượng cùng 2 lớp con cụ thể, một bạn gộp 2 lớp con thành một lớp duy nhất kèm một trường phân loại. Cách đó thật sự gọn hơn và cho kết quả in ra giống hệt. Nó cũng xoá mất đúng cấu trúc mà bài tập sinh ra để đánh giá, bởi mục đích của bài là để bạn thể hiện được kế thừa. Bài nộp đó đúng nếu xét như một chương trình, nhưng không chứng minh được gì nếu xét như một bằng chứng. Đề đặc tả 3 lớp, bài nộp có 1 lớp, và 2 lớp bị mất chính là 2 lớp mang điểm.
Luật rút ra hẹp và nên áp đúng nghĩa đen. Khi đặc tả gọi tên một lớp, một phương thức hay một chữ ký hàm, hãy tái tạo chính xác, kể cả cách viết hoa. Ý kiến thiết kế của bạn thuộc về những phần đặc tả bỏ ngỏ, và bao giờ cũng có những phần như vậy.
"Cấu trúc lớp phù hợp" nghĩa là gì khi đề không đặc tả gì?
Trả lời trực tiếp: Nghĩa là mỗi lớp giữ một trách nhiệm và giấu đi cách nó làm việc, sao cho một thay đổi bên trong lớp này không kéo theo hàng loạt thay đổi ở phần còn lại của chương trình. Đó là tiêu chí người chấm áp dụng khi đặc tả để bạn tự quyết cấu trúc, và tiêu chí này đã có từ bài báo của Parnas năm 1972.
Bằng chứng: Parnas (1972) đặt ra chính tiêu chí còn nằm dưới cách đánh giá này, lập luận rằng nên chia mô đun theo những QUYẾT ĐỊNH có khả năng thay đổi, chứ không chia theo các bước của một quy trình, để mỗi mô đun giấu đi một quyết định khỏi các mô đun khác. Dịch sang một bài tập năm nhất, một lớp phơi bày danh sách nội bộ của nó ra cho cả chương trình dùng là một lớp chẳng giấu được gì, và mọi lớp khác trở thành phụ thuộc vào một lựa chọn mà sau này bạn có thể muốn đổi.
Có 2 phép thử thực hành gọn trong vài phút, và cả 2 đều rút thẳng từ nguyên tắc che giấu thông tin của Parnas (1972). Phép thứ nhất là mô tả mỗi lớp bằng một câu mà không dùng chữ và. Nếu bạn buộc phải dùng và, nhiều khả năng lớp đó đang làm 2 việc. Phép thứ hai là tự hỏi cái gì sẽ hỏng nếu bạn đổi cách lớp đó lưu dữ liệu bên trong. Nếu câu trả lời là bất cứ thứ gì nằm ngoài lớp đó, thì tính đóng gói mà mô tả môn học nhắc tới thật ra chưa có.
Câu mô tả trên trang môn học không phải câu dẫn nhập cho có, nó đang gánh một định nghĩa có hiệu lực khi chấm bài. Nó nói rằng lớp gói gọn dữ liệu liên quan cùng các thao tác trên dữ liệu ấy vào một chỗ. Một lớp chỉ là túi đựng biến còn phần logic nằm ở nơi khác thì không phải thứ câu đó mô tả, dù chương trình vẫn chạy.
Vì sao kế thừa là chỗ sinh viên khựng lại?
Trả lời trực tiếp: Vì kế thừa trông như một cách để khỏi gõ lại mã, trong khi thực chất nó là một lời khẳng định về khả năng thay thế. Khi một lớp con không thể đứng thay lớp cha mà không làm phần mã đang gọi nó bị bất ngờ, cây kế thừa đó sai dù vẫn biên dịch được.
Bằng chứng: Liskov và Wing (1994) hình thức hoá yêu cầu này, cho rằng một kiểu con phải dùng được ở mọi chỗ mà kiểu cha được kỳ vọng, không làm thay đổi các tính chất mà phần mã gọi đang dựa vào. Liberman, Beeri và Ben-David Kolikant (2011) nghiên cứu 22 giáo viên tin học đang đi dạy khi họ chuyển từ lập trình thủ tục sang lập trình hướng đối tượng, và truy nguyên khó khăn của họ về việc thiếu một mô hình tư duy dùng được cho kế thừa và đa hình, chứ không phải về cú pháp. Người tham gia là giáo viên chứ không phải sinh viên năm nhất, nên hãy đọc phát hiện này như một phát hiện về KHÁI NIỆM, không phải về nhóm của bạn.
Cố vấn MAAS rút ra từ đó một suy luận, và đây là suy luận của MAAS chứ không phải của bài báo: nếu cái khó nằm ở mô hình tư duy chứ không nằm ở cú pháp, thì những câu phân loại điểm sẽ hiếm khi là hãy viết một lớp con. Chúng gần với dạng cho kiểu tham chiếu này và kiểu đối tượng này, phương thức nào được thực thi, tức là câu hỏi về điều phối động chứ không phải câu hỏi về kỹ năng gõ mã. Liskov và Wing (1994) đăng trên tập 16, số 6, còn Liberman và cộng sự (2011) đăng trên tập 11, số 1.
Một thói quen giúp ích: mỗi lần viết một phương thức ghi đè, hãy nói thành lời xem phương thức cha đã hứa điều gì, rồi kiểm xem bản của bạn có còn giữ lời hứa ấy không. Nếu bản ghi đè của bạn ném ngoại lệ ở chỗ cha trả về giá trị, hoặc không trả gì ở chỗ cha bảo đảm có giá trị, thì bạn đã phá vỡ khả năng thay thế, và đó là lỗi thiết kế mà một bộ kiểm thử có thể không bắt được.
Bộ kiểm thử tự động thật ra đang thưởng cho điều gì?
Trả lời trực tiếp: Nó thưởng cho những giao diện hành xử đúng y như đặc tả, kể cả ở các trường hợp không suôn sẻ. Hai trong 8 chuẩn đầu ra bao phủ kiểm thử, ngoại lệ và khẳng định, nên hành vi khi gặp lỗi là nội dung được chấm chứ không phải phần cẩn thận làm thêm.
Sinh viên viết cho trường hợp dữ liệu vào hợp lệ, bởi đó là trường hợp mà ví dụ trong đề bài đưa ra. Điểm số sau đó lại xoay quanh chuyện gì xảy ra với một tập hợp rỗng, một tham chiếu null, một chỉ số vượt ngoài phạm vi, hay một tệp không tồn tại. Một ngoại lệ được ném ra có chủ đích, kèm thông điệp gọi đúng tên vấn đề, là một câu trả lời đúng. Một chương trình sập kèm vệt lỗi, hoặc lặng lẽ trả về giá trị sai, thì không. Bốn tình huống vừa kể là 4 tình huống hay xuất hiện nhất trong bộ kiểm thử ẩn.
Hãy viết bộ kiểm thử của riêng bạn TRƯỚC khi viết phương thức thay vì sau đó. Danh sách này ngắn và phần lớn lần nào cũng như nhau: trường hợp thông thường, trường hợp rỗng, trường hợp một phần tử, biên ở mỗi đầu, và dữ liệu vào không hợp lệ. Với một bài tập có 8 phương thức công khai, 5 trường hợp mỗi phương thức cho ra 40 phép thử, và đó là con số hoàn toàn làm nổi trong một buổi. Năm trường hợp cho mỗi phương thức là một thói quen hợp lý ở mức này, và nó cũng buộc bạn quyết xem phương thức hứa điều gì trước khi quyết nó làm việc ra sao.
Bạn học lập trình bằng ngôn ngữ khác thì khác ở đâu?
Trả lời trực tiếp: Rào cản thường nằm ở tính tường minh của Java chứ không nằm ở khái niệm. Kiểu tĩnh, ngoại lệ có kiểm tra, cùng việc trình biên dịch đòi khai báo đầy đủ khiến Java nói thành lời những thứ ngôn ngữ khác để ngầm, và sự dài dòng đó bị đọc thành khó, trong khi thật ra nó là sự công khai.
Có 2 điều chỉnh mang lại phần lớn lợi ích. Điều chỉnh thứ nhất là đọc thông báo lỗi biên dịch như thông tin chứ không như tiếng ồn. Một thông báo lỗi của trình biên dịch Java thường gọi tên tệp, số dòng, kiểu được kỳ vọng và kiểu tìm thấy, tức là một chẩn đoán đầy đủ hơn hẳn thứ mà một lỗi lúc chạy đưa cho bạn. Bạn nào quen ngôn ngữ mà vấn đề chỉ lộ ra lúc chạy thường lướt qua các thông báo này, và như vậy là vứt đi phần phản hồi hữu ích nhất mà công cụ tạo ra.
Điều chỉnh thứ hai là từ vựng. Phần lớn đề bài dùng thuật ngữ rất cụ thể, gồm reference, instance, abstract, interface, override, overload và polymorphism. Overload và override chỉ khác nhau đúng một khái niệm và khác nhau vài điểm số. Bảy thuật ngữ vừa liệt kê đủ phủ phần lớn cách diễn đạt của đề thi INFO1113. Hãy giữ một bảng thuật ngữ ngắn gồm 7 mục, viết bằng lời của chính bạn, vì câu hỏi thi được viết bằng đúng những chữ này, và một câu đọc nhầm là một câu mất điểm.
Người ngoài giúp tới đâu thì hết hữu ích với mã được chấm điểm?
Với một bài lập trình được chấm điểm, ranh giới này sắc hơn bình thường, và một người viết hộ dù chỉ một phần mã là đã lấy mất phần bài đánh giá của bạn. Thứ một buổi học thật sự diễn ra là cùng đọc bản đặc tả trước khi bạn bắt tay vào làm, phác xem đặc tả đó thật sự đòi những lớp nào, rồi sau đó rà lại thiết kế của chính bạn theo các câu hỏi ở trên, đặc biệt là mỗi lớp có giữ đúng một trách nhiệm không và các phương thức ghi đè có còn giữ lời hứa của lớp cha không.
Nếu bạn đi theo hướng gia sư kèm riêng, tài liệu hữu ích nhất là một bài tập đã có điểm kèm theo bản đặc tả mà nó được viết ra để đáp ứng. Trong 8 chuẩn đầu ra, có 6 chuẩn mà một bài tập đã chấm sẽ lộ ra ngay bạn đang hụt chuẩn nào. Khoảng cách giữa hai thứ đó thường là chỗ điểm bị mất, và đây là cuộc trò chuyện về thiết kế chứ không phải về cú pháp.
Câu hỏi thường gặp
Sáu mã liên quan tới INFO1113 là những mã nào?
Ba mã mở đường vào là INFO1110, INFO1910 và ENGG1810. Ba mã chặn là INFO1103, INFO1105 và INFO1905.
Những môn nào mở cửa cho tôi vào?
Môn tiên quyết công bố là INFO1110 hoặc INFO1910 hoặc ENGG1810. Ngoài 3 mã đó thì không có kiến thức giả định nào, và quy định đầu vào được rà soát lại giữa các năm nên hãy kiểm tra trang của đúng năm bạn học.
Môn dạy bằng ngôn ngữ nào?
Java. Trong 8 chuẩn đầu ra, có 2 chuẩn gọi tên Java trực tiếp, bao gồm cả các giao diện và tập hợp thông dụng của ngôn ngữ này.
Tôi học INFO1103 hoặc INFO1105 rồi thì có học được không?
Không. Những mã đó nằm trong danh sách cấm học song song, cùng với INFO1905. Hãy xác nhận danh sách cấm của đúng năm bạn học trước khi lên kế hoạch đăng ký.
Bộ kiểm thử chạy qua hết thì bài đã xong chưa?
Chưa chắc. Kiểm thử qua chỉ chứng minh hành vi, tức 2 trong 8 chuẩn, trong khi nhiều chuẩn đầu ra nói về cấu trúc, cơ chế trừu tượng và khả năng đọc hiểu thiết kế, những thứ mà kiểm thử không đo được.
Tôi có nên cải tiến bản thiết kế đề bài đưa cho không?
Không nên. Hãy hiện thực hoá đúng cấu trúc được đặc tả, kể cả tên gọi và chữ ký hàm. Hãy để dành phán đoán thiết kế của bạn cho những phần đề bỏ ngỏ, và ghi lý do của bạn vào phần chú thích nếu bài cho phép.
Đọc thêm
Hỏi cố vấn MAAS về môn của bạn
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