October 29, 2012
Concepts
- Dr. Wong has redesigned the Java Resources page on his website so that it is easier to navigate. Dr. Wong finds it unlikely that he will be able to discuss all of the minute but important details of some of the topics that weĺl be doing soon, and therefore encourages everybody to visit the Java Resources page for in depth information.
- What is the “transient” modifier that is applied to the taskView instance variable inside of tasks? During serialization, an objects fields will be encoded into some stream of bytes, which will then be sent across the network. On the other end, Java will instantiate a new class of the same type, then insert all of the values that it finds in the serialized stream.
- Well, the taskView field is a reference to some other object; at some level just a number that identifies the other object. What would that number mean if we serialized it and sent it somewhere else? It would be meaningless outside the context in which it was created. /* This seems somewhat off-topic to me, because, as discussed below, this won’t happen. Java will attempt to serialize the entire referenced object. */ Transient indicates that the serializer should ignore the so-marked field.
- Note that normally, during serialization, the serializer will follow references (If Object A references Object B, and A is serialized, B will also be serialized). Be careful, therefore, not to serialize anonymous inner classes that close over other variables, as you can easily end up serializing and transmitting your entire system.
- Don’t confuse volatile and transient! volatile indicates to the Java Compiler that the value of some variable is not safe to cache (because the variable changes in parallel ways (?)) and that it shouldn’t try to optimize any code that uses the volatile variable.
- You can override (some interface…).readObject(…) (Something in Pi2.java…) if you need to do some sort of re-initialization whenever your Object is deserialized. You can call stream.defaultReadObject() to perform the normal deserialization, then take the opportunity to initialize your transient fields to some well-defined value.
Now we’re going to talk about generic list frameworks.
- Let’s take a generic list: IList<E>. What does it mean to run an algorithm on it?
- public abstract <R, P> R execute(IListAlgo<? super E, R, P> algo, P …)
- We declare that execute will return a type R: whatever the algorithm returns.
- We make a generic parameter P for whatever parameters the algorithm takes.
- ? super E: any algorithm that works on a supertype of E can work on this list of E‘s.
- Thus, we have a method, with generic parameters R and P (inside of an IList with generic parameter E), which accepts an algorithm that operates on a supertype of E, accepts parameters of type P, and returns a type R, and some number of parameters, each of type P.
- public abstract R emptyCase(IMTList<? extends E> host, P … inp);
- Declares a case in a visitor (the algorithm), that operates on any subtype of E.
Quotes
- “If you want a glass of water, there’s two components, right? The glass, and then the water! You only transmit the water from one glass to another; the glass is like the class, and the water is like the data.”
- “Never trust another programmer, especially not the one in the mirror.”
- “This is like the most intensely generic statement I’ve ever seen!” — Caleb
- “This is the easy one.” — Dr. Wong
Resources
Comments Off on Lecture 28: Generic Extended Visitors and Data Packets | Lectures | Permalink
Posted by iwa1
October 19, 2012
Ambient temperature: 73.4oF
Concepts
- Remote Method Invocation (RMI): What if your adapters in the MVC architecture took their input, schlepped it across a network to another computer, talked to an object on that computer, got its response, and schlepped it back across the network to you, instead of the simple wrappers around the model or view that they’ve been in assignments thus far? Well, then you’d have RMI, a way to call methods and interact with objects on different computers, over a network, in a way that looks like those objects are actually sitting there on your own computer. Properly-set-up RMI frameworks can make it very easy to write programs that operate over a network.
- In an MVC setup, the Model may be another MVC trio. The view may be another MVC trio. The controller will usually not be an MVC trio. In an RMI setup, there may be two distinct MVC trios on either end of the network, or the Model and Controller may be on the server, with lots of Views as clients. MVC describes three components and how they interact; it doesn’t require that all three always appear together, nor that they appear only in sets of three.
- “The RMI Registry” is someplace that RMI clients can consult to find out “who is online, and how do I talk to them?” RMI Servers add themselves into the registry for a given lookup key. Then, clients can ask “Is there a ‘hello’ server?” instead of having to search all possible places that a server could be, and checking the type of each server (which is not a task that is actually possible).
Quotes
- “Once I talk to the stub, the stub, like E.T., knows how to call home.” – Dr. Wong
Resources
- Lecture 25 Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec25/
- RMI Theory on COMP 310 webpage: http://www.clear.rice.edu/comp310/JavaResources/RMI/
- Oracle’s Tutorial on setting up RMI, complete with working sample code: http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/hello/hello-world.html
Comments Off on Lecture 25: Remote Method Invocation | Lectures | Tagged: MVC, rmi | Permalink
Posted by amw2
October 15, 2012
Ambient Temperature: 72.9oF
Concepts
- 2-3-4 Tree Powerpoint, slides 18 -> 20
- When implementing a self-balancing 2-3-4 tree (or any complex data structure, for that matter), think before you code. Take the time to devise solutions that decouple interfaces from implementation, and that separate the variant and invariant behaviors. When applying code to those solutions, again take the time to plan a solution that takes full advantage of the high-level interfaces and abstractions that you have set up.
- The exhaustive exposition of 2-3-4 tree implementation attempts to make the above point by presenting a concrete example that exhibits all of the desired qualities: Yes, you could have an insert(…), delete(…), etc method on the tree’s class, but that limits the tree’s behaviors to the few that you personally define. By instead providing an accept(TreeVisitor …) method, you are creating a tree that can perform arbitrary behaviors. If you wish to include some “out of the box” behaviors (like insert, delete, etc), you could either provide wrapper methods or a visitor factory. However, once you admit the visitor pattern into your data structure, it is inconsistent and likely inconvenient to maintain non-visitor algorithms (like a traditional delete(…) method) alongside visitor algorithms.
- This level of abstraction is absolutely necessary in large projects with multiple groups of developers, so you need to get comfortable with if you plan to ever get paid for producing code.
- Short preview of HW06 provided code: The visitor pattern was used to create the parser for the ABC music language. None of that is code that we’ll have to read or modify.
Quotes
- “We don’t have any servers at all. We just have Macbooks and beef jerky.” – Siegfried Bilstein, EGraphs
- “I have an anonymous inner class inside an anonymous inner class, and I’m gonna have another anonymous inner class inside of here…” – Dr. Wong
Resources
- 2-3-4 Tree Powerpoint: http://www.clear.rice.edu/comp310/f12/lectures/lec21/DP4SBT.ppt
Comments Off on 2-3-4 Trees Continued | Lectures | Tagged: 2-3-4 tree, insert, tree, visitor | Permalink
Posted by amw2
October 5, 2012
Ambient temperature: 74.5oF
Concepts
- There are three approaches to the “sum” algorithm on the NEList/MTList list structure:
- nonEmptyCase(…) { return MY_VALUE + rest_of_list.execute( this ); }
This is TAIL recursion, and accumulates the return value on the STACK. Another name for it is “Forward Accumulation.”
- nonEmptyCase(…) { return rest_of_list.execute( this ) + MY_VALUE; }
This is HEAD recursion (and therefore bad), and accumulates the return value on the STACK. Don’t do this. Another name for this is “Reverse Accumulation.”
- nonEmptyCase(…) { return rest_of_list.execute( new SumVisitor( MY_VALUE + VALUE ) ); }
This is TAIL recursion, and accumulates the return value in an INSTANCE VARIABLE inside the SumVisitor. This version allows your visitors to have, preserve, pass, and mutate STATE, which allows for more complex algorithms.
- Most of the list algorithms traverse the list; therefore list traversal is an INVARIANT behavior and should be abstracted out. Instead, “what to do with each subsequent value” is encoded in an Accumulator object, which is passed down the list by the visitor.
Resources
- Lecture 19 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec19/
Comments Off on Lecture 19 Part 3: More Visitors | Lectures | Tagged: accumulator, visitor | Permalink
Posted by amw2