COMP 310

Ambient temperature: 75.1^oF

Concepts

1. Fishworld uses “Affine Transformations” to make its fish turn to face the correct direction.
1. Everything takes place relative to the origin, and order of operations is important.
2. This is why CS majors must take math courses: Their concepts become freakishly germane in matters of computer graphics.
3. Dr. Wong advises us to always do scaling and rotation first, before transformation.
2. Any graphical element has one “prototype,” which is its state before any transformations have been applied to it.
1. The size of a prototype is “one unit.” The size of all subsequent instances of the prototype can then be described solely in terms of the scale factor (say “3 times”), without having to worry about multiplication anywhere.
3. Dr. Wong shows off his class hierarchy for Fishworld (from Lecture 12 webpage) – this would also serve the needs of Homework 3’s ballworld, though it would be overkill.
4. Math.atan2(double _y, double _x) will return a value that is rotated correctly into a quadrant; Math.atan(double _ratio) will only return a value in the first or fourth quadrant. If you want fish to rotate to properly face in the direction of its velocity, atan2 is your friend.
5. The Lecture 12 webpage is full of provided code and detailed design explanation for Homework 4.

Resources

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

Ambient temperature: 74.8^oF

Concepts

1. If you use reflection to instantiate a class, you must check that the constructor takes the correct amount of arguments, and that they are of the type your code expects them to be. Dr. Wong discovered that in Java 7, the behavior of Java Reflection’s Class.forName( class_name ).getConstructors() method changed, depending on whether the code runs in a 64-bit or 32-bit JVM. The 64-bit JVM returns the constructors in the order they were defined in the class file, which was the original behavior. The 32-bit JVM returns them in a different order. Dr. Wong did not do a thorough check to determine if there was a pattern to the 32-bit ordering.
2. Dr. Wong went over code and advice for Homework 3 in detail.
1. The Lecture 10 page on the course website contains full code for most of the Interfaces used in Dr. Wong’s implementation of Factories in Homework 3. These could be a good starting point and/or reference.
2. JComboBox<T> – only ever use a generic JComboBox, and never use box.getSelectedItem(); – use box.getItemAt( box.getSeletectedIndex() ); instead. The latter is generically-typed and will help you avoid errors.
3. When you choose a name for a generic class, choose something descriptive.
4. You will be choosing generic types for your classes, because you will use generics to make sure that the Model, View, and Controller are all using the same type of adapter. Furthermore, doing so will prevent a Model, View, or Controller from being used with another Model, View, or Controller that uses a different type of adapter. Type-safety is good!
3. Dr. Wong demonstrated Homework 4: FishWorld.

Quotes

1. “It’s whatever part of the shark I want it to be.” – Dr. Wong

Resources

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

Ambient temperature: 74.9^oF

Concepts

1.  We have learned two of the Four Pillars of Abstraction from the Lecture Webpage. Go read them.
1. Abstract Structure was demonstrated with various types of Balls inheriting from ABall,and us writing code only for ABalls.
2. Abstract Behavior was demonstrated by the “Strategies” that we will use in Homework 3 to make ball behavior highly configurable.
2. Today: The third pillar, Abstract Construction via the Factory Design Pattern. Factories implement an IFactory method that has a public ISomething makeSomething(…); method. Any class anywhere can use an IFactory to make objects that implement the ISomething interface, and it doesn’t care at all how they are constructed, or what they are constructed with.
3. Consider an IBallFactory that produces IBall instances. Concrete IBallFactories might include a StraightBallFactory, CurveBallFactory, and BreathingBallFactory, but your controller would only ever see them as IBallFactory objects. Any specifics of constructing a particular ball (perhaps BreathingBall needs to know how much it should breathe, or how fast) are handled by the individual factory instance, not by the controller.
4. Dr. Wong explains how JComboBox works: You can store Objects in it. Java will use their toString() method to display their labels. This can save you lots of time by allowing users to select instantiated Java objects (which then get fed into actionPerformed) directly.
5. Dr. Wong shows off his Strategy implementation:  His controller has a public IStrategy makeStrategy(String className) and public IStrategyFactory combineStrategy(IStrategyFactory one, IStrategyFactory two) methods. makeStrategy takes in a class name in string format and emit an IStrategy based on that class name. One of his strategies is a MultiStrategy that will take in two strategies and exhibit both behaviors. Chaining MultiStrategies leads to Color-Breathe-Straight-Curve balls, etc. MultiStrategy is used in combineStrategy to return a factory that uses both strategies.
6. Dr. Wong’s factory- and strategy- generation methods do so by creating closures in the … new IStrategyFactory() { … public IStrategy make() { … }  … } manner.

Quotes

1. “A factory that makes tress, and trees and trees and trees, of factories!” – Dr. Wong

Resources

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

Still struggling with MVC? Perhaps an alternate explanation will help…

Stanford University’s CS193P class’s Lecture 1 slides 11-37 provide a nicely illustrated overview of MVC: http://www.stanford.edu/class/cs193p/cgi-bin/drupal/system/files/lectures/Lecture%201_1.pdf

Open those slides up, then we’ll go through them and relate their elements to elements of HW02 and HW03.

1. Adapters a component in some implementations of the MVC design pattern. Adapters are not required in order for MVC to exist.
2. An implementation of “Target Actions” can be found in Java’s some_button.addActionListener( some_listener ); In this case, some_button is the view, and some_listener is the controller. In Homeworks 2 and 3, we don’t use this directly. Instead we either use an adapter from the Controller as the some_listener. Target Actions let data flow from the View to the Controller.
3. An implementation of “Delegation” is the “Strategies” that were introduced in Lecture 09. In Homework 2, you may wish to have the View as a delegate of the Model, so that the model can ask what size the screen is. This is not allowed in MVC (as the View and Model cannot talk to each other), so you should instead give the Model an  Adapter created by the Controller, that allows access to the view’s dimensions. In Homework 3, balls will have one or more IStrategy objects that they will call some method on which will modify the parameters used to paint, and then once the IStrategy(s) have finished, a ball will attempt to paint. These IStrategy objects could be given to a ball by a variety of sources. The balls are delegating the parameters of their painting to the IStrategy objecs. Delegation lets data flow into the View and Model from arbitrary sources.
4. An implementation of the “Radio Station” can be found in the Observable-Observer design pattern. In Homework 2 and 3, balls want to know when they need to update themselves, so they “tune in” (as Observers) to the (Observable) model’s radio station. When the model announces that it has updated, everything that is tuned in is notified. You may also wish for the View to tune in to the Model so it can update… but MVC doesn’t allow this. However, the View can tune in to an Adapter provided by the Controller… Radio Stations let arbitrary quantities of objects become aware of state changes in other, important objects.
5. “Target actions” are a one-to-one means of communication, while “radio stations” are a one-to-many means of communication. Delegation is a one-to-one means of communication. Any individual target action, adapter, radio station, or delegate is a one-way communication channel.
6. In cases where data needs to flow from Model to View or View to Model (“time to update the display” or “the add ball button was clicked,” for example), the message must make a pit stop at the Controller, who will route it and/or translate it to the right place. This can be accomplished in one of two ways. Method 2 is better MVC.
1. The Controller implements an IController interface that has all the methods that a View may need to call, and all the methods that a Model may need to call, implements the methods of that interface, then gives itself to the Model and View as the go-to guy for all tasks.
2. The Controller creates Adapters that contain that same code, and hands them out to the Model and View as necessary. The Model and View must implement IModel and IView interfaces that specify setter methods for the adapters.

Dr. Wong began the lab by asking who had already implemented MVC in their HW02 solution. Most people responded that they had. It seems this lab will focus on MVC and miscellaneous tips regarding HW03.

Concepts

1. There are two approaches to implementing adapters in the context of MVC. Dr. Wong reminds us that, in the end, it all comes down to decoupling the view from the model.
1. Every single event that the View can generate (each individual button press, etc.), gets its own individual adapter to connect it properly to the model.
2. There is a single IAdapter interface, with as many method specifications as are necessary to capture all of the events generated by the View.
3. Dr. Wong advocates a mixed approach, wherein semantically related functionality is grouped into a single adapter, and a Controller may instantiate and distribute more than one kind of these adapters. For instance, adding a ball and clearing all balls are somewhat similar in that they both manipulate the set of balls. Therefore, an IBallAdapter interface could specify the addBall and removeBalls methods. On the other hand, methods for updating and drawing the balls (updateBalls, paintBalls) based on a Timer tick may reside in an IUpdateAdapter.
2. To get started on HW03, Dr. Wong recommends to hold off on fancy painting (He seems to mean painting that somehow varies with time (something that changes shape or rotates / etc.)). We’ll get to that later. Also, until you have your Balls correctly using various Strategies, it is recommended to just hard-wire your dynamic class loader to skip the whole process of dynamic class loading, and instead to simply return an instance of some concrete Strategy.
3. Many HW02 submissions were still called HW01 in Eclipse. This is because SVN branching will only affect the SVN folder names, whereas Eclipse knows the project name based on metadata stored in the “.project” file. Be sure to rename the project inside of Eclipse after branching; otherwise Eclipse will overwrite the copy of HW01 that is on your computer.

Quotes

1. “Never delete something before its replacement works. In electrical engineering, they call that ‘make before break’” – Dr. Wong.

Resources

1. Lab 3: http://www.clear.rice.edu/comp310/f12/labs/lab03/
2. COMP-310 endorsed overview of MVC: http://cnx.org/content/m26104/latest/
3. MVC Explained (in more detail, with picture): https://comp310.blogs.rice.edu/2012/09/11/mvc-explained/

Ambient Temperature: 74.8^oF

Concepts

1. Practical demonstration of dynamic classloading in action – the JVM only loads the bytecode of a class into memory when the class is used by code that is running. When a hitherto-unknown class is requested by the JVM, it goes and tries to find the class, and loads the class if it succeeded in finding the class. The JVM does not care if the code was present, was compiled, or even existed prior to its attempt to load the class.
2. Demo of Homework 3: Ability to select two ball behaviors (such as “Curve” and “Color”(-changing)) and add a ball that exhibits both behaviors.
3. Dr. Wong will never have lush, curly hair. He blames his parents.
4. The downfall of inheritance-based ballworlds: You can only add behaviors by extending an existing behavior into a new one. If both CurveBall and ColorChangeBall extend ABall, you cannot produce a ball that posesses both of those behaviors with inheritance. You could produce a “CurvingColorChangeBall” that extends one or the other, but you would have to copy/paste code from one of them, because you cannot inherit from multiple classes. Additionally, inheritance is a compile-time feature that cannot be changed while code is running.
5. Composition
1. “Behavior as an entity:” encapsulate ball behaviors (such as changing color, or curving) as Java Objects to allow for potentially infinite and arbitrary combinations of behaviors.
2. IUpdateStrategy objects that take in an IBallContext Object representing the state of a ball (location, velocity, color, etc), and make some changes to it.
3. When updating, a ball will ask each of its IUpdateStrategies to operate on its IBallContext object. When every IUpdateStrategy has finished, the ball will use the data contained in the IBallContext Object to paint. In this way, any number of arbitrary behaviors can be exhibited by a ball and those behaviors can be assigned at compile-time and/or at run-time.

Quotes

1. (Shouting like Christian Bale’s Batman) “But we shall use our powers for good!” – Dr. Wong

References

1. Lecture webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec09/
2. Homework 3 Demo: http://www.clear.rice.edu/comp310/f12/demos/ballworld_compose/index.html

Ambient Temperature: 73.5^oF

Concepts

1. Pre-Game Show:
1. Join the Hacker Games with your @rice.edu e-mail for a not-quite-normal computer contest.
2. “The world is bigger than Microsoft, Amazon, and Google,” so consider interning or working for other companies, too.
2. When the “is-a” relationship of inheritance truly exists, it is acceptable to have a concrete sub-class of a concrete class. However, do not forget to use abstract classes where appropriate, not just at the top of the class hierarchy, to factor out common code.
3. Feel free to create ball types of your own imagination in Homework 2.
4. Two approaches to (Model, View, Controller) design for Homework 2:
1. The Model has a Timer which will use a Dispatcher to tell all of the Balls to update their positions. Every time the Model updates, it will use a Dispatcher provided to it by the Controller to tell the View the new information that the View should display.
2. The Controller has a Timer which will tell the Model to update its state, and then tell the View to update what it shows. The Model will use its Dispatcher to tell all of its Balls to update. The View will use an Adapter provided by the Controller to get the information it needs from the Model.
3. In all cases, when Buttons in the View are clicked, they will use Adapters provided by the Controller to communicate the necessary changes to the Model.

Quotes

1. “I’ve been told: be careful about watching BallWorld after imbibing certain substances.” – Dr. Wong
2. “You don’t put a fly method on a fish.” – Dr. Wong

Resources

1. Dem Dry Bones: http://www.brownielocks.com/dembones.html
2. Lecture webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec08/

Ambient Temperature: 73.8^oF

Concepts

1. Separating the Invariant from the Variant.
1. “Invariant” properties (and methods) live in the (abstract) superclass. Anything you put in AShape must satisfy the statement “All shapes everywhere forever have a ________.”
2. Things that can be invariant include (but are not necessarily limited to) a method’s presence, a field’s presence, a method’s implementation, and a field’s value.
3. Write programs targeting the Invariant (‘s interface), so that your programs can work with any, all, and arbitrary variants, including ones you may not have ever dreamed of.
2. Objects have behavior, which you experience when you interact with them, and a construction, which is how they’re built. When objects interact with each other in Java, they should only care about the behavior, not the underlying construction or data. Therefore, any object whose behaviors include “all of the things a duck can do” (for example) can be treated as a duck (for example) by other Java objects. Moral: Use Interfaces.
3. Concrete methods are rarely overridden, because that’s not what overriding is really for: If a child class is fundamentally changing the behavior, you’re probably doing it wrong.
4. Drive-by incidental introduction to “hey you can use wildcards in Java Generics.” Hand-waving ensued.
5. Observer-Observable design pattern will be necessary in Homework 2.
6. There are 32 different types of bridges, if you don’t count sub-types. Source: http://en.wikipedia.org/wiki/List_of_bridge_types

Quotes

1. “(paraphrased) What if I took some fluid and put it inside my duck robot so that when you stuck a needle in and drew it out, it contained DNA that perfectly matched your duck? Is that a duck?” – Dr. Wong
2. “Why isn’t there a bridge that swoops through the world and expresses the angst of society?” – Dr. Wong

Resources

1. Lecture Webpage: http://www.clear.rice.edu/comp310/f12/lectures/lec07/
2. Hipster Flipbook on YouToube: http://www.youtube.com/watch?v=4B3vNE459CQ
3. Wildcards in Java Generics: http://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html

Concepts

1. Don’t ever call paintComponent or new Graphics(…); because they are provided for you by Java’s graphics framework, which is exists before your code starts running and whose purpose is to make it easier for us to do graphics.
2. Model-View-Cotroller^[2]Design Pattern:
1. The “Model” knows what your program is, and what its state is.
2. The “View” knows how to display objects.
3. The “Controller” knows how to tell a View to display a Model, and how to update the Model based on user input.
4. The Model and the View never interact with each other; they only talk to the Controller.
5. Use the MVC design pattern for Homework 2 even though it’s not required, because it will be required for Homework 3.
6. WindowBuilder’s MVC will start the View instead of the Controller, which is wrong. Change the generated code to start the Controller instead.
3. Balls (in Homework 2) move discretely, not continuously.
1. If a ball passes the edge of your screen and bounces back and forth on the edge, it’s because you are making it bounce every time it is across a wall, rather than once per wall.
2. How do you know where a ball would have been, if it discretely passes the edge? http://www.clear.rice.edu/comp310/f12/assignments/hw02/BallBounce.png
4. Dr. Wong says “SVN Branch your Homework 1 code to use as the starting point for Homework 2.”
1. Consider instead:
1. Duplicate HW01 in Eclipse.
2. Rename HW01 to HW02 in eclipse.
3. Commit HW02 to SVN.

Quotes

1. “Assume a spherical cow (in a vaccum).” – Dr. Wong (and peanut gallery)
2. “I had an older brother, and to him, I provided the ‘punchingBag’ service. I didn’t know when he would call on that service; he could just walk up whenever he wanted and OOMPH” – Dr. Wong

Resources

1. Animations: http://www.clear.rice.edu/comp310/JavaResources/animation.html
2. MVC Design Pattern: http://cnx.org/content/m26104/latest/
3. Copying a Source-Controlled Project: http://www.clear.rice.edu/comp310/Eclipse/Subclipse/copying/