Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
*waves hand* This is not the page you're looking for.
...is currently here.
Part 1: What are the differences between creational, structural, and behavioral patterns?
Creational patterns solve problems associated with creating classes and instances. For example, creational patterns can be used to control access to object creation, to modify how the object is created, or to choose the class of the object to be created at runtime. (Source: CreationalPatterns and examples)
Structural patterns deal with interfaces and composition. In other words, they illustrate ways of designing objects to build on each other to reach the goals of encapsulation and object reuse. (Source: StructuralPatterns and examples)
Behavioral patterns are concerned with program flow, or how one object passes information to another. Patterns related to event handling, message delegation, etc. fall into this category. (Source: BehavioralPatterns and examples)
Part 2: Describe an Interesting Pattern
The Strategy Pattern is a type of behavioral pattern that is useful when you want to be able to perform a certain task in multiple ways. In other words, you want to call a certain method but choose from several implementation algorithms at runtime. For example (one that I intend to use for SqueakPoint, no less!), suppose an object wants to set its layout. Instead of doing it directly, it delegates the details of the operation to a LayoutStrategy that has been assigned to it. By assigning a different subclass of LayoutStrategy, you can easily change the layout algorithm of the object. It's still accomplishing the same task (in this case, doing the layout), but it's accomplishing it in different ways (flow layout vs. box layout, etc). (Source: StrategyPattern)
Part 1: In detail, describe a problem that you experienced in Squeak. What was the problem? Why did it happen? How did you eventually overcome this problem?
The biggest problem I've had using Squeak is the user interface itself. Specifically, the window management is extremely rudimentary (it's the equal of Windows 3.1 or TWM). There's no dock or taskbar or shelf, for example; instead there's only the ability to "collapse" them. Unfortunately, this is insufficent because the collapsed windows can be obscured by other ones (unlike with a dock or taskbar). There is a "layout" submenu, but I haven't successfully used it yet (for example, when I selected "table layout" all the windows (and tabs) lined up in a column, with most of them off the bottom of the screen).
The Squeak Windows Menu
Switching between windows is relatively difficult, too. The only immediately obvious way is to click on the part of the target window that is showing, but that's impossible if a window is completely covered by another. There exists a Windows Menu that has such useful features as "find window," "collapse all windows," "expand all windows," "close top window," and "move top window to back;" however, it's inconvenient to access because it's a submenu of the Desktop Menu. Some of the functions do have shortcut keys, but for some reason I can't get them to work on my Mac.
These problems are exacerbated by the fact that Squeak tends to encourage having large numbers of windows. As such, it really needs good window management more than, say, a docking-pane IDE like Eclipse would. The suggested solution, "just get a bigger monitor," is a ridiculous cop-out, and is doubly so given that Squeak is supposedly written by HCI experts! Besides, a bigger monitor isn't an option anyway, in many cases. Tabbed windows, docking panes, or – the best option – Exposé would go a long way towards making the UI more usable.
As for a solution, well, I haven't really found one yet. The closest I've come is to make the Windows Menu persist (by clicking the pushpin in its upper-right corner), so I can access it's functions with a single click. However, I still can't use "collapse all windows" because it collapses the menu itself, too! I'm still looking for a way to cycle through the windows with a shortcut key, as well as being able to do so backwards. I'm also trying to figure out the trick to getting layouts to work right.
Of course, these aren't really solutions anyway, becuase a true solution would work easily and intuitively the first time, by default.
A typical cluttered Squeak desktop
Part 2: Other useful posts
The post by Jiasheng He about the Whisker Browser is really interesting. It looks as though that might be part of the solution to my window management problem! It's just too bad that it's not part of the official distribution of Squeak.
Nazli Dokuzoglu's post is useful because it provides a good overview of some of the basic methods of interaction in Squeak.
Short Essays (from Spring 2001 midterm review)
- Explain how object-oriented programming is related to simulations
A simulation is a representation of a system, and a system is a group of disparate components, interacting to accomplish a common purpose. The simulation represents the system by modeling the components and their interactions.
Object-oriented programming is a method of creating computer simulations. "Objects" are the components of the system, and the "messages" they send to each other are the interactions. The resulting program is the simulation itself.
- What is a CRC card? What are they good for? When do you use them?
A CRC card lists the name of a class, its responsibilities and the classes it collaborates with. CRC cards are good for object-oriented analysis, because you can model the problem just by writing cards for each candidate class and arranging them on a table. They are also useful because they're simple enough to explain to non-technical people (e.g. marketing and users).
- Explain in what sense inheritance is a form of delegation
Inheritance is a form of delegation in that the child class its delegating its basic operations to its parent (e.g. when an object sends a message to super), and also that the parent class is delegating the the responsibility of defining some of its operations to its children classes (e.g. when something performs an action on a list of Shapes, but the actual objects are Circles or Squares or Triangles and override the action).
- Why is it useful to think about objects as "biological cells"? (Hint: Think about scalability and about modularity)
Biological cells are similar to objects because they are instances of a well-defined class (e.g. brain cells, blood cells), they have an inheritance hierarchy (e.g. the superclass is stem cells), they have internal structures (e.g. DNA, mitochondria, etc) which are like instance variables, they perform specific functions (e.g. blood cells carry oxygen), and they can work together to compose larger structures and perform larger functions (e.g. muscle cells make up the heart, which pumps blood).
Catagory: Virtual Machines and Garbage Collection
Question: Compare and contrast the following garbage collection algorithms: reference counting, mark-sweep, generation scavenging. How do they work, and what are the pros and cons of each?
Reference counting involves using a counter variable to store the number of references to an object. Each time a reference is added the counter is incremented, and each time a reference is removed the counter is decremented. If the counter reaches zero, the object is freed.
- It's an easy, simple algorithm.
- Unused objects can be indentified and freed immediately, instead of having to perform a search through the entire heap to find them.
- It uses extra space because it requires storing an extra integer with every object.
- Every time a reference is assigned to another, it has to do extra arithmetic to increment/decrement the reference counter. This can also interfere with things on the stack.
- Doesn't work correctly with cyclic memory references.
Mark-sweep keeps track of objects by arranging them in a tree structure, where the roots are statically-allocated or stack-allocated references, and all other objects can be found by following pointers from the roots. Instead of running incrementally as reference counting does, mark-sweep waits until the program runs out of memory. It then performs garbage collection in two phases: first, it traverses the trees, "marking" each object as it goes. Second, it "sweeps" over the entire heap, freeing everything that isn't marked and unmarking everything else in preparation for the next scan.
- Able to handle cyclic memory.
- Normal assignment incurs no overhead.
- Because it waits until the program runs out of memory and is a long-running algorithm, it causes the program to freeze while the garbage is collected.
Generation scavenging is a modification of mark-sweep whereby objects are classified into groups based on how old they are. The rationale for this is the generational hypothesis: the idea that the longer an object as been around, the more likely it is to continue to be used. This is because younger objects are likely to be temporary. By dividing the objects up like this, the younger objects can be garbage-collected more often than the older ones, improving efficiency.
- More efficient than just doing mark-sweep on the whole heap at once.
- Yet more stuff to keep track of.
Thoughts on Teamwork
Here's a quick list of, in our experience, what works and what doesn't regarding teamwork:
- Pair programming. This applies to all programming languages, but especially Squeak. We found that the project required writing relatively little code (in terms of number of lines), but that it could be very difficult to figure out exactly what those lines of code should be. Having two minds on the same task is extremely useful, not only because you'll be able to come up with a better design, but you'll also be able to catch each others mistakes, and – most importantly for Squeak – you'll be able to search through the class browser twice as fast to find the objects you need!
- Face-to-face meetings. Having your group go to the States lab or wherever to all work on the project together may be inconvenient, but it's well worth it. Most people are much more productive when their teammates are around to poke them if they get off-task, and if you're not one of those people then you ought to meet with your team anyway so you can poke the others!
- Contracts. Some of our team members lacked motivation, and we eventually turned to Jeff for help. His most useful suggestion was to give the slacking team members specific tasks with specific deadlines, and make them agree in writing (or, at least, via email) that they would complete those tasks. Most importantly, failure to fufill the contract should have clearly-defined penalties, such as being kicked off the team (and the professor should be aware of the contract, so that he can help enforce it).
- Segmentation. Break the project into little tasks. I don't just mean the milestones; I mean break each milestone up into "mini-milestones" or something. That way, when you combine it with the contract strategy above, you'll end up having deadlines for little bits of the project before the milestone deadline, and it won't be disaster if somebody doesn't get their stuff done in time.
- Having conflicting schedules. At the beginning of the semester when you're choosing your team, check to make sure you all have at least a few hours a week when you're all free at the same time. If the schedule of half your team conflicts completely with that of the other half of your team, then for the love of all that's good in the world, find somebody else!!! (If you happen to look at our team page where we listed our schedules, you'll notice that this was the major problem we had.)
- Not setting goals. At the beginning of a milestone, don't just have everybody in the group go off and "think about working on the project." Chances are, it won't get done. Do your design as a group, and only then assign specific tasks to each team member.
- Procrastination. This one is obvious; it's mostly here for completeness. However, don't underestimate how big of a problem it can be! The instant you notice a teammate (or yourself!) even just starting to procrastinate, do something about it (such as assigning contracts as mentioned above).
- Anti-procrastination. Don't err the other way, either, and complete the entire milestone by yourself way ahead of time. I don't care how bored you are, let your less-motivated teammates do their part (unless, of course, they're behind schedule like in our case). All this does is make you resent the rest of your team because you're doing all the work, and makes the rest of the team feel bad because they want to do their fair share, but don't get the chance. Remember, not everybody has the time or strength of will to get their work done a week before it's due. Let them do it on their own schedule (within reason).
Links to this Page