Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
22, recently married
- Lessons learned from the case-studies (Playwriting Workbench)
We learned that prototype code doesn't necessarily have to be perfect. It can simply be building "enough" to show that the application is functional and then focus on the design aspect of the project after going through the Learner-Centered Design phase (general focus on support and motivation, as well as usability). Prototyping generally involves iterative design and implementation as well as testing of the developing prototype.
- First, list desired features.
- Second, list scenarios – i.e. the way the user will interact with the features.
- Third, use CRC Cards to lay out a basic design, but do not worry about UML since this is prototype code.
- Code away
Although it is prototype code, use ground-up objects where needed to prevent having to rewrite the entire application later, if it is necessary to implement a fully functional version. It's important to realize that a prototype doesn't just allow for feature showcase, but can be the basis of a functional, well designed application in the future and thus should be built as one, even if we are not going through all of the steps of proper OO design.
- What is Inheritance?
- What is Delegation?
- What is Polymorphism?
- What is Encapsulation?
- What is the MVC paradigm? (For an example show an example using MVC)
1) The OO idea that all functionality of one class is passed from one class (the superclass) to another (the subclass)
2) Using another object to perform a task needed to perform the upper level task is delegation
3) The OO idea that you can overload methods in a super or abstract class – such as shape – to implement specific functionality for classes that inherit from shape (i.e. different area methods for circles, squares, etc.)
4) The concept that objects have their own data and actions which cannot be accessed by another object without permission
5) MVC stands for model view controller. The idea is a design pattern used to separate a program requiring user interaction into three distinct parts. The model represents the data portion of the program. The view represents the portion of the program that actually displays information (the GUI portion). The controller is the part of the program that accepts user input and can either modify the view, the model, or both.
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?
While working on milestone 2, I happened upon a nasty, nasty side-affect to incorrect calls to super. While extending a Morph class/subclass, a call to "super." in the initialize method will crash Squeak in a very nasty way. It essentially halts it, you can do nothing except close the program via conventional means (killing the process or clicking the "X").
The problem is simply an incorrect method call. Instead of calling "super." one should call "super initialize." – specify what super class method you are calling – it isn't like Java overloading where you can call super and the language knows you are implicitly calling the overloaded method. It happens because the functionality to simply choose the method you mean to call isn't in Squeak – it's up to the developer to call super class overloads explicitly. I didn't – one of my group mates noticed my headache and took a quick look at the code, compared it to his and we found the issue. I suspect the Squeak devs will implement this functionality in a later release.
What are the differences between creational, structural, and behavioral patterns?
To answer the aforementioned question, I'll simply break it up into the three subcategories, defining each one followed by a short segment on their inherent, defined differences.
Generally speaking, design patterns are ways to solve a design problem formed using some standard pseudo language. More specifically design patterns are not algorithms (a way to solve a computational/mathematical problem). Patterns are completely versatile and reusable generic solutions to design problems such as information hiding and decoupling. Patterns also cut down on code maintenance, the most costly part of application development.
Patterns, as the delegated question poses, come in three flavors: creational, structural, and behavioral. While the names of the categories hint at their meanings, they are not completely descriptive. For this reason, I’ll attempt to give more insight into their meaning.
“Creational patterns define mechanisms for instantiating objects. The implementation of the creational pattern is responsible for managing the lifecycle of the instantiated object.”
What does that mean? How do you definite the mechanism for instantiating objects? It’s quite simple. Just like all real-world objects are created in some sort of factory, for example, you can use an AbstractObjectFactory to create the object of your choice depending on input. The usefulness of such a strategy depends on the application. If one is designing a small self-use application, the use of an ObjectFactory is unimportant. On the other hand, if one is designing an enterprise-class, scalable application, the use of such a design pattern is a must to simplify the coding methodology and the design. It reduces class dependencies which saves maintenance time when the application has grown substantially.
Another creational pattern is the Singleton. This is another useful pattern that limits the life of an object to a single instance. This is useful, again for the enterprise, but also for smaller applications like a small chat server, or the like.
“The composition of objects and their organization to obtain new and varied functionality is the underlying basis of Structural patterns.”
Structural patterns, such as Adapters, simplify the way objects and existing classes interface with new implementation. By using an interface and changing its implementation, the class being interfaced with never knows the difference. This, again, is a way to simplify code maintenance.
Another structural pattern is the Proxy. Proxies simply mediate communication between objects and “play the role” of one of the objects. This is useful in remote/networked applications for security purposes. Only the data that is required is transferred.
“Interaction between different objects is specifically covered by Behavioral patterns.”
The most common behavioral pattern is the Iterator. Iterators define a standard methodology for accessing items in a list, completely hiding implementation of the list from the calling object. This is useful for a number of reasons: it reduces class coupling, increases information hiding (of the list implementation), and simplifies object method calls.
In short, creational, structural and behavioral patterns set a basis for solving design problems and in turn increase the likelihood that a design will truly meet the object-oriented model. Creational patterns simplify the object life cycle, structural increase information hiding and reduce coupling, and behavioral simplify object interaction.
Please note that part 2 of my discussion is included with part 1, above. I've described several patterns in detail, emphasizing the creational type.
Since the article is rather long, I'll focus on just a few of its main points:
- Built-in Security
- Memory Management/Garbage Collection
Interestingly, Each of the languages discussed support multithreading capabilities except for two: Perl and Visual Basic. Of the others, all of them either offer support inherently, based on implementation (i.e. some versions of SmallTalk do not), or via external libraries, such as C++. Ruby, in particular, offers completely self-contained threading capabilities, allowing it to exhibit these features in platforms that do not support threading, such as MS-DOS. This does, however, have the major side-affect of halting the terminal if a system-level call is made. This has the potential of lifting a slight burden off a programmer required to code for an older platform, such as those working to produce software for industrial fields.
Java, Ruby, and Perl provide "out of the box" functionality in this area, preventing many of the security mishaps that have been exploited in other languages, such as ActiveScript. This again lifts the burden off the programmer and allows them, to some extent, to focus less attention on security when coding particular applications, such as Java applets, and more on the functionality of those applications.
Memory Management/Garbage Collection
C++ forces the developer to handle all memory management. This is a mixed blessing. It allows for a developer to write a lower-level application while maintaining a pseudo-object oriented structure. It also has a speed benefit, but can cause issues when used improperly (i.e. reading past the end of an array, etc.). Both SmallTalk and Java offer garbage collection, this functionality lifts the majority of the burden off of the programmer regarding memory management. It is, however, still possible to generate a memory leak through the improper handling of references to objects no longer in use, so this functionality is not 100% effective and it cannot be.
http://www.jvoegele.com/software/langcomp.html receives credit as the source of my information.
Reflections on other posts: Derek DeRaps' post
"During initialization, C and C++ run three to four times faster than Java, and five to 10 times faster than the scripting languages."
I would venture to say that the author's experience is anecdotal (not Derek, but the author of the article). I work as a part-time developer for a major telephony company here in Atlanta. Our software is mainly Java based, and our competitor's software is mainly C++ based. Our software performs just as well as theirs, call to call, etc. This maybe anecdotal evidence as well but my point is that while C++ is certainly faster, 300-400% is not likely in the majority of applications and that much of the performance burden lies on the application design and implementation strategies used in the application.
Links to this Page
- Fall 2005 Who's Who last edited on 9 June 2011 at 5:25 pm by cc-vpn-tso249.cc.gatech.edu
- Fall 2005 Teams last edited on 14 December 2005 at 2:01 pm by lawn-199-77-215-180.lawn.gatech.edu
- Team RobotChicken last edited on 28 October 2005 at 12:17 pm by washington-win.cc.gatech.edu