COMP 310

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

Concepts

1. A “Debugger” is a program that can attach itself to a JVM running your Java program in order to let you pause the execution of your program at specific points in your source code called “break points.” Once your program is paused, you can do many useful things. The two most useful things a Debugger lets you do are:
1. See the value that variables actually have at run-time.
2. “Step through” the execution of your code one line at a time.
2. Together, these two features of Debuggers make it possible to see what your program is actually doing when it is running, which can be very useful in tracking down certain bugs.
3. Debugging in Eclipse is very easy: Click the “Bug” icon  to run your program with a debugger attached.
4. Not very much interesting will happen unless you have set up some breakpoints. To add a breakpoint, double-click to the left of any line of code:
   

   No Breakpoint

   Double-click on line 142…

   

   Breakpoint Added

   Now, the Debugger will pause the program right before line 142 runs.

5. When the Debugger pauses a program at a breakpoint, Eclipse will open the “Debug perspective,” and provide some controls to you
1.  “Step Over” will move to the next function call or line of code in the file that contained the breakpoint. In the example above, the FIRST “step over” will run until _default_strategy.make_strategy(). The SECOND “step over” will run all of the code in _default_strategy.make_strategy(), and pause still on line 142, ready to run new MotionSwitchStrategy(…). The THIRD “step over” will finish line 142’s new MotionSwitchStrategy, and pause at line 145. “Step Over” is the way to get to the line that you really care about.
2.  “Step Into” will run the very next line of code, wherever it may be. In the example above, the FIRST “Step Into” will also run until it finds _default_strategy.make_strategy(), as that is the very first thing that must happen on line 142. The SECOND “step into” will go to the file that defines whatever type of object _default_strategy is – in this case, it is an anonymous inner class created in the Controller, so we’ll be sitting at line 1 in the controller. The THIRD “step into” will go to the first line of the make_strategy() method. You could then use “step over” to walk through the lines of code in make_strategy(). “Step Into” is a good way to dig into the inner workings of the line of code you care about.
3.  “Step Return” will run through lines of code in whichever method you are currently in, until a “return” line is found. It will complete the return, and then pause again. In the example above, clicking “Step Return” anywhere inside the make_strategy() method will bring us back to line 143, where make_strategy() has just finished completing. “Step Return” is the quick way to get yourself out of a hole you dug yourself into with “Step Into.”
6. When debugging, you can help yourself understand what is going on by only having one method call per line of code. Instead of the example code above, the following would be much easier to debug:
   

   Easier to Debug

Resources

1. Debugging in Eclipse: http://www.clear.rice.edu/comp310/Eclipse/debugging.html
2. Screenshot of Eclipse’s “Debug Perspective:” http://www.clear.rice.edu/comp310/Eclipse/debug_screen_annotated.png

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/

Concepts

Today, Dr. Wong only lectured for about 8 minutes. He encourages us to work on command dispatchers and on creating an infectious strategy.

Resources

1. Lab 05: http://www.clear.rice.edu/comp310/f12/labs/lab05/

Ambient temperature: 73.2^oF

Concepts

1. Dr. Wong is in a food coma from BBs Cafe, probably because today is his birthday.
2. Never do ball.get_update_strategy().update();. That is an encapsulation violation! Instead, use ball.update_state(), and inside update_state(), the ball itself may ask its update strategy to update(). Or, the ball may implement its updating in an entirely different manner, but it doesn’t matter because encapsulation is intact.
3. Your balls should have some method (Observer’s update() method could be a good place, if you’re using Java’s Observer-Observable framework) in which they will execute all of their commands.
4. Anonymous inner classes are important because they create Closures of their current environment, allowing you to have access to the Graphics object and any other Adapters you might want, without having to pass any of them as parameters to a method or a constructor.
5. Commands are introduced in-depth, with sample code.

Quotes

1. “And those fields [captured in a closure] never disappear, unlike your hometowns that get turned into suburban wastelands or plains of townhouses.” – Dr. Wong

Resources

1. Lecture 14 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec14/

Ambient Temperature: 73.2^oF

Concepts

1. Dr. Wong explains how proper MVC design facilitates launching ballworld as a Java Applet, by showing how the demo pages’ code was set up and invoked.
2. Dr. Wong demonstrates “Infection Balls,” “Eating Balls,” and “Bouncing Balls” as part of the command-driven ballworld demo.
3. Some pool halls have cue balls that are smaller than normal.
4. Strategies are used with a specific purpose in the mind (paint, update, etc) of the object that uses them. Commands are used without any specific purpose in the mind of the object that uses them. IPaintStrategy may have a paint() method, IUpdateStrategy will have an update() method, etc. When these methods are called in code, the object calling them will be calling .paint() because it wants to paint. An ICommand will have only an apply() method, and when a command is run in code, the object running it won’t know why, or what the command does – only that it should run the command.

Resources

1. Oracle’s Java Applet Tutorial: http://docs.oracle.com/javase/tutorial/deployment/applet/
2. Lecture 13 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec13/

Ambient temperature: 73.2^oF

Concepts

1. Systems with prototypes do not care where the prototypes come from, so long as they have one. Have a “IPrototypeShapeFactory” hierarchy that can produce the prototype (size ~ 1.0 units) of any kind of shape, when you need it.
2. Polygon and Image factories cannot store a unit-sized prototype; they will instead store whatever size is available. When asked for a prototype, they will apply a transformation to create a reduced-size version that is unit-sized, then return that new version instead of their “internal” prototype.
3. The Decorator Design Pattern allows you to extend or customize the behavior of one instance of an Object, versus the entire class of Objects. If you wanted exactly one specific ball to always be a color that the user chooses, for example, but didn’t want to write “AlwaysRedStrategy, AlwaysBlueStrategy, AlwaysGreenStrategy…” implementations, you could create a Decorator class that wraps a Strategy instance, and forces that one instance to always paint a particular way.
4. The Template Design Pattern features an Interface, implemented by an Abstract Class. That Abstract Class implements the default behavior of each of the Interface’s methods. Wherever possible, it breaks this default behavior up into a series of other method calls in the Abstract Class (NOT in the interface). These methods are an example of “extensibility hooks.” To customize the behavior of a sublcass, programmers then override just the hook methods that deal with the behavior they want to modify. For example, instead of overriding and completely re-implementing paint(Graphics _g) { … } just to change the color, a Template-based Abstract Class might define the protected abstract void prepare_color(Graphics _g, IUpdateContext _c) method, which you would override instead. That way, you do not have to re-write code for painting, transforming, or any other behavior. This is another way of “separating the variant from the invariant.”
5. Variable Input Argument Lists were introduced.
1. The JVM does not implement them; they are compile-time syntactic sugar, therefore
2. Java Reflection does not (and can not) support calling vararg methods.
3. You cannot pass a single object that is an array.
4. They are a convenience feature only; no new capabilities are granted, so
5. Just don’t use them.

Resources

1. Lecture 12 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec12/
2. Lecture 13 webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec13/

This lab is really meant to assist with HW04, but due to scheduling, we’re doing it now. Dr. Wong suggests that you branch your HW02 or HW03 (depending on which is more complete) into Lab 04.

Concepts

1. In your MVC, the line “import  model…” and “import view…” should only ever appear in the Controller. The line “import controller…” should not appear anywhere in your Model or View.
2. Basically, we want to turn all shapes into unit-sized entities centered on the origin, as this will most easily permit us to use affine transformations in drawing. For a circle, “unit size” seems pretty clear: unit radius or maybe unit diameter. For a strange shape, however (Dr. Wong draws something that looks like a squashed bug), “unit size” is less  defined. Maybe it is the circle that most tightly encloses it? Maybe it is a circle whose radius is some average of the distances between the points around the perimeter and the geometric center? etc.
3. It’s important to center your objects around the origin before you start transforming. Otherwise, transformations can easily affect them in drastic and undesired ways.
4. Dr. Wong suggests trying to load and draw an image as part of Lab 04. Images can be tougher, as images’ origins are in their upper left-hand corners. Dr. Wong suggests using paintCfg(…) to reposition the image somehow to put it at the origin. Keep in mind that you’ll need to maintain the aspect ratio of non-square images when transforming them to unit size. Also, if your image contains a large whitespace border around the content, you may need to use test collision with a shape that is somewhat to substantially smaller than the rectangle of the image. Also, make sure the content of your images is centered within the image :D.
5. Some of your shapes (including images) will have a non-identity “initial transformation” that will bring them to unit-size at the origin. Then, you can layer other transformations on top of this initial one to draw it wherever you need it. You should do this because you really don’t want to alter image data to bring it to an initial state: scaling images would lose resolution, etc. Instead, just composite multiple transformations to achieve your goal.
6. Note that all of these transformations are reapplied during every draw; you never permanently alter your images or other shapes, but instead just set up the Graphics2D correctly each frame to draw through the transformations.
7. If Dr. Wong or another staff member has not yet looked at your MVC design, he urges you to have it looked at to avoid losing points on HW03 and beyond.

Quotes

1. “It’s like a never-ending battle, and I’m always losing.” — Dr. Wong on trying to adjust his class schedule year after year.

Resources

1. Lab 04: http://www.clear.rice.edu/comp310/f12/labs/lab04/