Circle:public. We had to add that when we implemented methods from an interface, remember?Prof: So all fields and methods can have one of several visibilities, which affect which other classes can use them directly. The ones we’ve been encountering implicitly are:
private– the field or method can be accessed only within the class or within classes declared in the same file, for the kind of programs we write (ones with avoid main())- No modifier given (called “package private”) – the field or method can be accessed only within the class or other classes in files in the same “package” (roughly a folder)
public– any context can access the field or method
radius is made private:record Circle(int radius, Color color) implements Pict {record fields have private access. It’s by default and it can’t be changed.records pull off – it’s helpful to be able to see the private fields’ values. So records also add a public accessor method or getter with exactly the name of the field. So going back to our Point class that corresponds to a record, it would actually look like:public makes sense because the job of a record is to construct data. So the defaults all make sense. And records are actually doing quite a bit of typing for us (and saving us tedious reading), because we want these patterns over and over.Prof: You know, I partially agree with you. But there’s a good argument for keeping fields private, and it’s what most people actually recommend! The idea is that it limits where you have to look to see what happens to a particular field. If you want to ask a question like “does this int field only ever increase” that’s a very complicated question to answer if any code in a big program could change it. But if you have all the uses of the field in one place, you can audit that quickly.
Especially these days with agents adding code all the time, things like private help set up some boundaries so you can still check a guarantee like “my field only increases” even if thousands of lines of code are added outside that class.
Prof: Um, well, the equals method is a little weird. And I left out something called hashCode that is not relevant for what we’re doing right now. We will have to directly address updating equals when we talk about the Object class, but that’ll be another day. There’s one more detail of record that I want to share now, though.
Record fields are what’s called final, which means you can’t do field update on them.
class declarations can have field updates applied to those fields. So one step more honest would be to put final in:Practice
Raster is a class in Pict.java with private fields pixels, width, and height, and methods width(), height(), and colorAt(x, y). In your program, r is a Raster and c is a Circle. Which of these lines compile? Select all that do.int w = r.width();width()is a method ofRasterthat it lets you call.int w = r.width;widththe field isprivate, so only code insideRastercan use it.Color first = r.colorAt(0, 0);colorAtis howRasterlets you read one pixel.Color[][] all = r.pixels;pixelsisprivate.Rasternever hands out its array.Color col = c.color();A record writes an accessor method for every field.Color col = c.color;A record’s fields areprivate, even when you didn’t write the word.
private and final. Which of these can code outside the record do?- Read a field’s value, with its accessor methodThe accessor method is
public, so anyone can read the value with it. - Change a field’s value after the record is built
finalmeans no field update, not even inside the record, once it’s built. - Read a field directly, with
.and the field nameFrom another file, the field itself isprivate. The accessor method is the way in.