COMP 310

Ambient temperature: 73.4^oF

Concepts

1. 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.
2. 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.
3. “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

1. “Once I talk to the stub, the stub, like E.T., knows how to call home.” – Dr. Wong

Resources

1. Lecture 25 Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec25/
2. RMI Theory on COMP 310 webpage: http://www.clear.rice.edu/comp310/JavaResources/RMI/
3. 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

Ambient temperature: 74.1^oF

Concepts

1. Q&A session about HW06
1. Don’t confuse “ticks per quarter note” with “ticks per default note.”
2. Don’t fret over tuplets.
2. 2-3-4 Trees: Deletion Heuristics (slides 21 -> end). Basically, “Push the element to delete down to child nodes, until it is at a leaf node. Then, just remove it.” That allows you to keep the tree balanced while doing the deletion.

Resources

1. Homework 06 webpage: http://www.clear.rice.edu/comp310/f12/assignments/hw06/
2. 2-3-4 Tree Powerpoint: http://www.clear.rice.edu/comp310/f12/lectures/lec21/DP4SBT.ppt

Ambient Temperature: 72.9^oF

Concepts

1. 2-3-4 Tree Powerpoint, slides 18 -> 20
2. 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.
3. 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.
4. 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.
5. 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

1. “We don’t have any servers at all. We just have Macbooks and beef jerky.” – Siegfried Bilstein, EGraphs
2. “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

1. 2-3-4 Tree Powerpoint: http://www.clear.rice.edu/comp310/f12/lectures/lec21/DP4SBT.ppt

Ambient temperature: 73.8^oF

Concepts

1. 2-3-4 tree theory and implementation, slides 1 -> 17.
2. Identify the invariant properties of the data structure, and build variant behaviors with them.

Quotes

1. “Imagine a really big Christmas tree sitting on a little spike on the bottom, maybe you’re cheap and buy a really little spike on the bottom, you look at the big ones and they’re really expensive so you buy a cheap one, and you put your tree on it (extends arms and tilts back and forth).” – Dr. Wong

Resources

1. 2-3-4 Tree Powerpoint: http://www.clear.rice.edu/comp310/f12/lectures/lec21/DP4SBT.ppt
2. 2-3-4 Tree Demo: http://www.clear.rice.edu/comp310/f12/lectures/lec21/dp4sbt_demo.html

Ambient Temperature: 74.1^oF

Concepts

1. Extended Visitor Design Pattern: Instead of a host calling visitor.this_type_of_host_case(…), the host can call visitor.case_for_host( host_type, parameters… ). This allows your visitor to have a set_case_for_host( host_type, ICase _case ) method that will add behavior to the visitor for the specified host type. The end result is that you can support an arbitrarily large number of hosts that can be set at design-time, compile-time, and/or run-time.
2. Make sure to have a”default” command for host types that do not have a specific command mapped to them.
3. Lecture 21 (using the extended visitor pattern to implement self-balancing tree data structures) was briefly introduced.

Quotes

Resources

1. Lecture 20 Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec20/
2. Demo of Exended Visitors: http://www.clear.rice.edu/comp310/f12/demos/ExtendedVisitorDemo/
3. Lecture 21 Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec21/

Ambient temperature: 74.5^oF

Concepts

1. There are three approaches to the “sum” algorithm on the NEList/MTList list structure:
1. 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.”
2. 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.”
3. 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.
2. 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

1. Lecture 19 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec19/

Ambient temperature: 74.4^oF

Concepts

1. Dr. Wong demonstrates the visitor design pattern:
1. The HostA-HostB-HostC visitor pattern from last class’ lecture.
2. Linked Lists with counting, summation, copying, and mapped addition.
2. The visitor pattern is an example of “double dispatch:” First the visitor object is dispatched to a host object, then a particular method is dispatched from the host to the visitor object.
3. Accumulators: Unfortunately, still forming a succinct summary; got distracted by loop invariants :(

Quotes

1. “What is a duck? A duck is a thing that acts like a duck.” – Dr. Wong
2. “Ducktyping is about ‘can we use it as a duck?’ What I’m talking about is ‘how do we define a duck?'” – Dr. Wong

Resources

1. Lecture 19 webpage on visitors: http://www.clear.rice.edu/comp310/f12/lectures/lec19
2. Simple visitor demo: http://www.clear.rice.edu/comp310/f12/demos/VisitorDemo/
3. Linked list visitor demo: http://www.clear.rice.edu/comp310/f12/demos/ListFW/
4. Double dispatch on Wikipedia: http://en.wikipedia.org/wiki/Double_dispatch

Ambient Temperature: 73.8^oF

Concepts

1. A representative from Palantir Technologies came to talk about their company and encourage attendance of their info session tonight from 5:30pm to 6:50pm in Duncan Hall 1064. The advertised dinner will consist of Star Pizza.
2. Interpreter Design Pattern:
1. An abstract class for a category of objects defines an abstract interface that each concrete subclass implements in its own way. Our first design of Shapes, with an AShape defining a paint() method, was an example of this design pattern.
2. To add behavior to the category of objects, you add a method to the abstract interface. (To add behavior to an AShape, you would add a method to the AShape class.)
3. A problem arises if we have lots of behaviors: If we have 300 different behaviors, our class will have 300 different methods.
4. Another problem arises if we want to change the behavior at runtime: All of these methods and their code are determined at compile-time, and we can’t change that.
5. A third problem arises if we want to allow third-parties to add behaviors: Since all of the behavior was written by us and compiled into the .class files, third parties cannot easily add behaviors into existing objects.
6. All of these problems can be summarized by the following idea: The algorithms are tied to the data structure. These problems are solved by the
3. Visitor Design Pattern:  The interface for a category of objects simply states that it accepts “a visitor for this category of objects.” Algorithms are encapsulated inside visitors. When an object accepts a visitor, it provides information to the visitor as determined by the Visitor’s interface, and calls the visitor’s algorithm. The key points of implementation are illustrated on the lecture webpage, and described below:
1. The IBall interface defines public <T> T accept(IBallVisitor<T> _visitor);
2. The IBallVisitor<T> interface defines a method for each logical sub-type of an IBall. For example, if there are three concrete ball types: ImageBall, PaintedBall, and CompositeBall, the IBallVisitor<T> will define
   public T ImageBallCase(ImageBall _b);
   public T PaintedBallCase(PaintedBall _b);
   public T CompositeBallCase(CompositeBall _b);
   public T DefaultCase(IBall _b);
3. ImageBall will implement its accept method as
   public <T> T accept(IBallVisitor<T> _visitor) {
        return _visitor.ImageBallCase(this);
   }
   and so forth.
4. If a new type of ball that doesn’t have its own special case in the visitor still wants to participate, it uses the DefaultCase method.
5. As a result, an algorithm that runs properly on any collection of IBalls can be encapsulated inside an IBallVisitor. Adding algorithms does not require modifying the data structures (IBalls or their concrete subclasses), and anyone, even third-parties, can add new algorithms at any (compile or run) time.
6. An added benefit is that an unknown algorithm (IBallVisitor<T>, but you don’t know which concrete implementation) can be run on an unknown host (IBall, but you don’t know which concrete implementation), and the actual code that is run will be the correct method in the concrete visitor with the host available as a parameter with a specific, concrete type. This lets you write fully-generic, abstract, type-safe and type-checked algorithms without relying on instanceof or reflection.
4. If a task depends on an object, delegate the completion of that task to the object.

Quotes

1. “plumber dot fix toilet” – Dr. Wong

Resources

1. Lecture 19 Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec19/

Ambient temperature: 73.5^oF

Concepts

1. It is entirely possible to make incorrect design decisions, and these can fairly easily be identified. However, there are often multiple correct answers to a given design decision, and it is not always clear-cut which one is best. Dr. Wong implies that it is not as important to choose the best design decision so much as it is to choose a correct one.
2. When two balls collide, they may be overlapping. If you do not take their overlap into account when applying collision impulse, the balls will immediately collide again and do the wrong thing. A simple solution is “Nudging,” as described on the lecture webpage. The derivation of the mathematically correct solution is also provided.
3. Visitor Design Pattern is introduced as a way to allow arbitrary algorithms to be run on composite data structures.

Resources

1. Lecture 15 webpage (collisions): http://www.clear.rice.edu/comp310/f12/lectures/lec15/
2. Mathematically precise handling of ball collisions with overlap: http://www.clear.rice.edu/comp310/f12/lectures/lec15/Collision_calculations.pdf
3. Visitor Design Pattern: http://cnx.org/content/m16707/latest/

Ambient temperature: 73.8^oF

Concepts

1. Remember perfectly inelastic collisions from high-school physics? You’re gonna need them. Or not, as Dr. Wong has prepared all of the equations and code for you.
2. Stop, think, and talk about your design decisions. Most importantly, make design decisions.

Quotes

1. “Bro, my view frustum won’t permit that.” – Student

Resources

1. Lecture 15 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec15/