The article I read was entitled "The Evolution of Object-Oriented Languages" by Matt Weisfield, a Professor in Cleveland Ohio. The article focuses mainly on the emergance of certain OO traits, through the evolution of programming requirements, and uses this to create a direct comparison between Java and C++.
One of the first things that the article focuses on the subtle but important differences between many OO (or seemingly OO) languages that have been in use in the past. The papaer discuess the fact that many of the OO languages used today are sort of adaptations of different languages. For example, C++ was originally called "C with Classes" because of it's direct relationship with C, and Java, originally named "Oak", was a take from C++ with or without features that were deemed favorable or not.
The article gives a rundown of many of the OO languages in today's programming world. Just to summarize:
The article then briefly discusses the ideas of what constitutes a "State-of-the-art OO Language" (focusing on a direct comparison by the OO giants, C++ and Java). Here is a rundown:
Basically, in a sense, many of the OO languages today are based loosley on the same ideas. However, these ideas don't necessarily translate into a strict OO implementation, as seen with C++ and Java. OO languages today keep evolving and popping up, as someone will have a new idea on a particular implementation. This was seen in the emergance from C++ to Java to visual J++ to C#.
After having read Nirav Shah's discussion, I can see that he noticed many of the same differences that I read about in this article. I would also agree with Nirav in that there is "no easy programming language". OO presents ideas about programming in an easier, real-world sense (i.e. sending messages to objects....tell a desk to change color), however, I believe that there still much work that needs to be done before OO becomes the 'programming environment for children' as pointed out in one of the first lectures in class
Link to article: The Evolution of Object-Oriented Languages
In a general sense, design patterns are organized into three different categories according to particular purposes that the patterns serve. These categories are creational, structural, and behavioral.
Creational design patterns are primarily concerned with patterns that focus on the creation of objects. For instance, one pattern that falls into this category is the Factory Method, which provides a pattern for producing "concrete classes by separating the constuction of complex objects from their representations" (Wegener). In this way, one could create a factory interface for producing any number of different objects based on the needs of the situation.
Structural patterns, on the other hand, focuses not on how objects are created, but how they relate to one another. The general aim behind this pattern is to allow "classes with incompatible interfaces work together" (Wegener).
Finally, whereas structural design concentrates on how classes relate to one another, the main point of behavioral design is to centralize the relationships between classes with emphasis on the communication between objects. The idea here is to provide a simplistic and repeatable way to carry on communication between objects that normally would be difficult to implement. According to Wegener, these behaviors "can be based on state, request handling and object interaction".
There are many design patterns that are interesting and extremely useful in many situations. One pattern that I find particularly intriguing is the factory pattern, categorized as a creational type of design pattern. As with other creational patterns, the factory pattern provides an interface for creating any number of objects, in which the resulting class is not openly declared ("Factory Method Pattern"). I originally saw this pattern in a lecture in CS 2335 (link). The lecture mentioned the general purpose of the design and gave a very interesting example involving encryption keys. In this example, an EncryptedSocket has access to a IEncryptFactory, which is subclassed by an EncryptionFactory. The EncryptedSocket doesn't necessarily know the type of encryption object is needed, but the Encryption Factory does. This EncryptionFactory produces either DESEncryption or RSAEncryption objects, which are subclasses of Encryption, which is used by the EncryptedSocket to encrypt/decrypt information. I thought this was a very good example, and it allowed me to really grasp the concept. To sum up the idea, a particular needs an object for a particular use. However, the specific usage of which, may change, based on particular circumstances. This is when the factory steps in. Using the circumstances, the factory decides what object to create for the purpose. The owner of this factory creates the object needed for the task by simply asking the factory to create an object for its needs. For example:
Say we are writing a media player. We want to play different audio encodings, not necessarily one particular kind. We can have access to a MusicFile object, which has subclasses MP3File, WMVFile, and OGGFile. We can use a MusicFactory to produce the one we need.
MusicFactory factory = new MusicFactory();
MusicFile mySong = factory.generateMusicObject("Some Info");
I suppose what interests me most about this convention is that the actual object generated is abstracted to a point where we don't really care the specifics about what we are getting, just that we can use it to suit our needs. As of right now, I can't say that I can think of any immediate situation where I would use this. Although, I'm not saying that it isn't possible this semester!
One of the most frustrating things that I found out in squeak was reading in files. I don't know how long I looked for decent documentation on how to use a FileList2. The problem I was having was not necessarily how to use the FileList2, per se, there was plenty of information on that. What I couldn't find information on was how I could take the file that I just got from the FileList2 and actually use it! So here's a little documentation on how to read in a file (an image, say) and actually use it!
The first that we'll need to do is actually get the file, which is done by directly using the FileList2 class using the message(s)
The first will read in any file, while the second will only show files of the supplid extension in the file listing window. Now that we've read our file in, we actually have to do something with it. For this example I'll be reading in an image. This is the point at which I became frustrated; there was no documentation for this and I had no idea how to do it. If you're reading in an image, you have to take the file that you picked from the FileList2 and convert it into a Form object using the Form class. And as it turns out, the Form class has a class method fromFileNamed: which uses a filename to create a new Form from the file! We can use this as follows (from the file1 and file2 example:And as it turns out, both file1 and file2 both understand the name method, which returns the actual filename.
And that's it! Now that you have read the image in and created a new Form object, you can do just about whatever you want. For example:will take the Form object, apply it to a new SketchMorph, and open it for viewing in the World screen.
Java has recently become very widely used as a language for quickly developing reliable cross-platform applications. Some of the benefits of using java for a project include:
C++ has long-since been the industry standard for robust, high performing applications. Here are some of the benefits:
Smalltalk is a language developed a while ago and has been known as a system designed for non-programmers and children (as opposed to C++). Benefits include:
|Actually, many Smalltalk VMs are faster than Java, so the Sluggish VM is not really a problem. The Squeak port of StarLogo is actually faster than the Java version, because it was able to use a primitive. In Java, you can't create your own primitives. Smalltalk may have been created for children, but that effort really failed. Smalltalk is too complex to be used by children. It's syntax might be simple in comparison to languages like C++, but children still had a hard time doing OO programming. Smalltalk is however a great language to create new languages, so perhaps it would be appropriate for creating a new language for children. I'd also quibble with C++ as a standard for robustness. Any language where programs regularly segfault can hardly be called a model for robustness. If you are interested in an OO language for robustness, check out Eiffel.|