Objects to Protect Private Details Memento and Iterator

Objects to Protect Private Details: Memento and Iterator Snarf the iterator code for today’s class.

GE Software Engineering Opportunities CS & ECE Students are you tired of playing with toys? Put your imagination to work on something bigger… Want to learn more about what GE has to offer you? Join us at the E-Social TODAY Bring Your Resume!

Discover Your Future RANKED #3 Internship & Co-op Programs Rotational Leadership Programs Direct-Hire

Internships & Co-ops • 3 -month summer internships • 6 -month semester co-op • Hands-on engineering and business experience • Key path to full-time positions upon graduation

Edison Engineering Development Program (EEDP) • 2 -3 year technical program • 6 -12 month long rotations in engineering • Intensive technical training • Tuition reimbursement for graduate degrees • Corporate leadership training

A Problem Mike is building a cool Secret. Agent object. He wants the object to be savable in a variety of different forms (e. g. in the cloud, on the local filesystem, etc. ). Mike really wants to keep code that deals with data storage out of the Secret. Agent class. So he makes a new set of classes to deal with writing Secret. Agents to files. But there’s a problem….

We Don’t We Just Add a get. Real. Name() function? • It violates the encapsulation we want for the secret agent object • Encapsulation: keeping data that we don’t want external folks to know about of the public interface • It’s not about security - it’s about expressing your intentions clearly to the folks that use your classes

We could add a get. Encoded. String() function • The encoded string stores gets all the private data of Secret. Agent encoded in a particular way • Then we add a new constructor (or Factory Method) to Secret. Agent that takes an encoded string as a parameter and recreates the object from the string • Still slightly problematical: what if someone starts pulling data out of the encoded. String? (again, we’re concerned about mistakes not malicious programmers)

Memento: A Solution • Change get. Encoded. String() to get. Memento() – a function that returns a Memento. Object • The Memento class has no public methods (or at least it seems that way) • Now it is more obvious that no one except special folks are intended to get data out of this object • Our special constructor (or factory method) now takes the Memento – making it super explicit how the Memento is used to reconstruct the object

How to actually get data out of Memento • Secret. Agent. Writer needs to get data out of the memento. How can it do that if it has no public methods? • C++ has a special friend keyword that will let you give access to your private data to certain other classes • In Java, there is no official way but you can do tricks like this:

A Problem: Adding undo functionality to Argo. UML • Argo. UML has a UMLDrawing with many private members. Your thought is that you will add a new method get. State() to the UMLDrawing that returns a memento. • Every time a change is made you’ll call get. State on the drawing and save the state. Then if the user ever wants to restore the state you can use the memento to do that. • How would you use Memento to do all this? • What new functions would you need to add to UMLDrawing (I needed to add 2). What new classes/interfaces would you need to add (I needed to add 2)

Argo. UML • I added to UML Drawing: – public Memento get. State(); – public restore. State(Memento old. State); • Class/Interface wise I added: – The interface Memento which has no methods – The private inner class UMLDrawing. Memento (implements Memento) which has all sorts of methods to get at that stored state

The Key Idea • The memento object encapsulates the private data of a different object • The memento can be passed around safely and gives other objects new functionality (in particular the ability to store the state of this object…even if they don’t know what that state is)

Another Problem • I’m writing a Linked. List class • Oftentimes, in algorithms that use linked lists you want to be looking at several different parts of the linked list at once • I don’t want to expose to my clients that my Linked. List class consists of List. Nodes (because I might want to change that in the future) • BUT I do want my clients to be able to write efficient algorithms that look at several parts of the linked list at once

Iterator • Encapsulates the idea or being in a specific place in a data structure • Often has methods has. Next and next (which gets the next, and modifies the state) while(iterator. has. Next()) { My. Object current = iterator. next(); //do stuff to current } • Sometimes also has methods like remove() or add() which add/remove at the current position

Java’s Iterable • If you have a collection class in Java, you can often make it implement the interface iterable<Type> • You have to implement a method iterator() • If you do, you can use your collection like this: for(My. Object current : my. Collection) { //do stuff to current } • Equvalent to: Iterator<My. Object> iterator = my. Collection. iterator(); while(iterator. has. Next()) { My. Object current = iterator. next(); //do stuff to current }

Iterator Problem • You’ve got a class String. List which contains a list of strings, which you want to allow folks to iterate over (in the order the strings were added, just like a normal list) • The string list might contain duplicates, but when you iterate you want to only visit each unique string once (that is, you want to ignore duplicates)