1.5 - Encapsulation

Is encapsulation important?

"Encapsulation is one of the 3 big concepts when we talk about object oriented programming"

There were basically two methods outlined in this reading

1. Return a copy of the object 2. Use different fields. He used arraylists and made one of them modifiable and one of them only readable.

What is Encapsulation?

Encapsulation is the process of hiding all the details of how a piece of software works and describing only enough about the software to enable someone to use it. Encapsulation is grouping functions and variables into a class Encapsulation lets us do information hiding Encapsulation and information hiding lets us control what has the rights to edit what values

Defensive Copying Conslusion / Notes https://javacreed.com/what-is-defensive-copying

Important takeaway: Don't return mutable objects with public methods. That breaks your encapsulation

What's the name of the keyword that goes first when you're writing instance variables for a class?

Access Modifiers

What's the name of the tool you use to control what sees what instance variables?

Access Modifiers

What does API stand for? What is it? What is our API in our classes?

Application Programming Interface An application programming interface is a computing interface which defines interactions between multiple software intermediaries. It defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc. Public methods are the API to our class

In a nutshell, what is defensive copying?

Basically, it's where we return a copy of an object instead of an actual reference to the object. If we have a straight getVariable method, it will return a pointer pointing at the actual object, which will expose its private methods. If we use defensive copying, that will not happen. Here is some example code of how to do it with an array. Not sure if there is a specific way to do it for each kind of field, or how we'd do it with returning an object.

When we do the copy constructor, why are we allowed to NOT use the getters?

Both of these below code lines are ok. The reason is that the constructor is WITHIN the class, so it's ok for it to see how itself works. We don't need to protect it from itself. We'd want OTHER classes to use the getters instead of the dot operator. this numerator = original.getNumerator(); this numerator = original.numerator;

Where do you put the access modifier in front of?

Classes, instance variables, and moethods

When is a copy constructor helpful?

Copy constructor is helpful when we want to copy an object that is heavy to instantiate.

What's one way to avoid copying code in your constructor and your setter?

Example: If you have an int field that you don't want to accept negative values, instead of checking for that BOTH in the constructor and in the setter, you could just have your constructor reference your setter. Image attached of how this code works.

What is a copy constructor?

It's a constructor where you pass in an existing object as an argument to the constructor, and it copies all those attributes over to a new object with a new pointer pointing at a new object on the heap. Image attached.

Do we always want to include setters and getters? Give some examples of why or why not

NO Getters - we wouldn't want to include getters for things like passwords. We can have a method that's not a getter that checks the password when we're checking if it's right, but doesn't outright return the value. (sensitive cause passwords, I'm sure we'll learn the actual way if we ever touch passwords) Setters - We don't always want to expose raw setters. If we have a locker, and there's a method that is used to fill the locker (if it's empty), we wouldn't necesarily want to ALSO have a straight setter exposed, because then a user could use the setter to override the full/empty status of the locker. Question from me to me - Could we have the setter if this class wasn't exposed to users? Like what if there's 3 different methods that for different reasons might change the empty/full state of the locker, then IF this case wasn't exposed to users, and was just exposed to a higher level class, would it be ok to have a setter, so that the 3 other methods didn't have duplicate code??

What should be the default access modifier for instance variables (attributes)?

Private

What are the main access modifiers?

Public Private Package Protected

What's the default access modifier for classes?

Public. Usually.

How do we want to NOT access our data?

The bad way is keeping all the instance variables public, and using something like exampleObject.intField = 10; This would work if hte field was public, but it is bad practice. We want to use getters and setters instead, but know that getters can also result in unwanted access to fields.

The correct way to make a copy constructor is with a "deep copy". Attached is an image for how to do so. With things like ints and strings it seems pretty easy. With mutable objects like the belt object here, it seems a bit more complicated. I don't fully understand it yet, but he said for array objects, we need to make copies for each of the objects within array objects.

The correct way to make a copy constructor is with a "deep copy". Attached is an image for how to do so. With things like ints and strings it seems pretty easy. With mutable objects like the belt object here, it seems a bit more complicated. I don't fully understand it yet, but he said, we need to make copies for each of the objects within objects.

Bad practice of encapsulation

Using getters that return mutable objects. For example arrays.

When is it important to use defensive copying?

When we're using a getter of a mutable object (like an array or a list)

What's a common way to allow limited access to a class's attributes and data?

With getters and setters