This document gives some initial, non-exhaustive advice to those who want to do a bit of preparation for 0320 in the week before the semester starts. This document focuses entirely on Java and OO, not setup of the tools 0320 uses for Java, which is covered in class and at hours in the first week of the course. You can find our setup guide here.
The semester's EdStem board has been enabled. Everyone enrolled and with the course in their cart should have access, although late adds will require a manual button click. If you have questions related to this assignment, or preparing for 0320 in general, please make them as replies to the Preparing-for-32 post, rather than making a new thread.
Students who complete CSCI 0190 may move directly to intermediate and upper-level courses without taking CSCI 0200. However, as the intro course guide says:
Many students go on to take 0200 after 0190, especially if they did not have a strong grounding in object-oriented programming prior to starting at Brown.
We strongly suggest taking 0200 before taking 0320. If you plan to move directly from 0190 to 0320, you should be aware that 0320 assumes a baseline familiarity with object-oriented programming in Java. While we do review some OO material, there are many vital ideas that we can't cover, either in class or in gear-up sessions. There is no one assignment, or collection of readings, that can substitute for a full-semester experience in 0200---but for those of you who plan to skip 0200 regardless, the material below can provide some guidance.
CSCI 0320 provides access to Joshua Bloch's Effective Java (3e), which is available online via Brown's library. Effective Java is not a "Java textbook"; you might consult 0200's lecture notes for that purpose. Rather, it's a series of focused OO design tips written by one of Java's authors; some are Java-specific, but often they even contain useful wisdom for OO programming outside Java.
You should be able to access the book in two steps.
- Navigate here to setup your Brown-affiliated account. Select "Brown University" and log in---note this login is Brown-managed.
- Access the online reading here. Either click "Continue" or use the table-of-contents menu in the upper-right corner of the screen to begin.
Here is a (non-exhaustive) list of readings in Effective Java that will be useful in adopting the "0320 mindset" when it comes to OO programming early in the semester. Some of these will be assigned reading for everyone, but we suggest getting an understanding of the core point of all of these. (Some reading is better than none!)
-
Encapsulation
- Item 15: Minimize the accessibility of classes and members
- Item 16: In public classes, use accessor methods, not public fields
- Item 17: Minimize mutability
- Item 18: Favor composition over inheritance
-
The power and dangers of inheritance
- Item 10: Obey the general contract when overriding equals
- Item 11: Always override hashCode when you override equals
- Item 12: Always override toString
-
Generic types
- Item 26: Don't use raw types
-
Exceptions
- Item 73: Throw exceptions appropriate to the abstraction
-
Q: Will working in Java mean that we can't program functionally?
- A: No. The lessons you learned about functional programming in 0170, 0190 or 0200 will still be useful. E.g., Java has supported lambdas for quite some time. (See Item 42 in Effective Java.) The difference is that you'll need to learn more concepts to program with objects and do it well.
-
Q: Will you provide us with solutions to this (and other) assignments?
- A: 0320 is a different sort of course. You're moving into a larger world, where there's almost always no perfect solution, especially when it comes to OO design. We'll review candidate sprint solutions in class, but the code reviewed will almost always have both weaknesses and strengths. We won't be releasing a "solution" to the assignment-zero prompt below.
-
Q: What's the deal with grading, mandatory S/NC, and collaboration?
- A: While the 2023 syllabus isn't finalized, you can see some of 0320's philosophy in last semester's syllabus. Yes, you'll be free to share (even required to share) your code. Yes, we'll be requiring you to follow professional standards about doing so.
This public repository contains a starter codebase in the chessish
directory. The codebase is a Java project, and uses Maven to resolve dependencies---you can recognize Maven projects by the pom.xml
file in the project root, which contains configuration information for Maven.
This existing code is somewhat more complex than you'll write for the first assignment (CSV), and roughly the same complexity as the code you'll write for the third assignment (Server). It's an intermediate stage in my (Tim's) effort to author a chess program. Actually, that's not quite right; if it was only meant to play chess, it wouldn't need to be this complex. Instead, we're trying to make a codebase that can handle many similar, but different, games.
In the past, you've probably focused on writing code that is fit for a purpose. It satisfies the assignment spec, or does what you need at the moment. You might have also tried to write code that is easy to understand or free from bugs. In 0320, we'll write code that is also resilient against external bugs and ready for change or extension. When I (Tim) wrote this code, I was thinking mostly about extensibility and safety. If I shared my code with someone, could they easily extend it to play Go as well?
This is an exploratory exercise, meant to help you understand the "0320 mindset" better, and reinforce your OO-programming skills. The starter code is incomplete and imperfect, although it can be run.
You may modify this starter code in any way you wish. E.g., you may change the classes I wrote, add new classes, new main
methods as alternative starting points, etc.
There are three parts to this assignment.
First, run a game of (pawns-only) chess without changing the code. (Run ChessGameMain.java
.) Then look through the code. What do you notice that might be new or different? What questions do you have, and which can you answer yourself? (It's OK not to understand everything. Part of this assignment is about noticing that and identifying questions.) Keep a record of these questions.
As an example of what I mean, here are some starter questions for you to investigate:
- Why does the
Pawn
piece type only return possible moves, rather than actually making any of those moves? - The
IllegalAction
custom exception stores aPosition
as well as a message, and comments suggest that this is to ease debugging. Why? - Which assumptions about the game does the code make? (Try to express essential constraints, like "the board is two-dimensional", that might be difficult to remove in future versions.)
- Why does the
Action
interface,Move
class, etc. exist, when a chess move can always be represented by a pair of locations? - What design choices in this code make you nervous? Can you concretely explain what your concerns are?
It is vital for you to understand that, although the above questions may have reasonable answers, the design choices in the starter code do contain flaws (as most code does). It is also vital to ask other questions of your own. The goal of this exercise is not to teach you a list of "Java tricks" to always follow, but to give you practice thinking about design.
Next, look over the testing class (it's in the src/test
directory, not src/main/...
). I wrote only one test; surely more testing would be good. But what kind of tests should I write? Take notes on what tests you think are important, but missing. Then write at least two tests: one that tests the outcome of a complete game (a "system test" for the overall game-playing program), and one that tests some lower-level functionality (a "unit test" for a class or method).
Finally, extend the codebase in some way. Here are two suggested paths:
- You might add another chess piece---I only coded the logic for pawns. This would probably be another class, just like
Pawn
, that describes how that new piece moves. - You might leave chess behind, and see if you can use this codebase to run a game of Go instead. There, you'd also need a new piece type, but a
Move
is probably not what you want---once placed, Go pieces can be captured but not moved. What assumptions am I making that could interfere with playing Go? Is there anotherAction
type that would work better?
This semester, we do not have the TA capacity to grade your solutions to assignment zero. We also understand that you don't have the entire break to work on this. However, to prevent overlap of effort with the first "real" assignment in 0320, we consider this "due" on January 26th (the first day of 0320). Even if you can't do everything above, some is better than none.
We're collecting your brief written responses to the above prompts via this Google form.