Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
My name is Joaquin Estrada. I am a third year Georgia Tech student majoring in Computational Media. This webpage is dedicated to my work for CS 2340. Hobbies: Frisbee, Music, Laughter
For discussion 1, I read an article called "Comparing OOP Languages". The link to the article is: http://www.geocities.com/Paris/5675/paradigma/tarea2.html
Here are my observations:
When it comes to compile time type checking C++ is a little less efficient than Java because C++ has been written to be compatible with C (a non OOP language). Smalltalk and CLOS tend to do more of the type checking at runtime. Thus, this can have an effect on coding time required depending on how soon the coder becomes aware of faults in the code.
OOP “pure” languages, like Java, are easier for newcomers to learn than OOP hybrids such as C++ and Object Pascal (OP) because Java only deals with one paradigm (OOP) where as C++ and OP incorporate traditional C and Pascal programming approaches (which tend to be procedural) which can sometimes contradict concepts as you combine two paradigms.
Smalltalk is technically more OOP oriented than Java because the primitive types in Java, while not classes themselves, can be in wrapper classes. This has the effect of making Smalktalk less efficient because less shortcuts have been made prior to coding.
Memory allocation: When it comes time for memory allocation, C++ condenses commands and makes it easier to create and do something with an object than Java or OP. Also, C++ and OP give a more direct access than Java does to “pointers” (partially because has no official pointers) because of security reasons.
Trash collection can make a programmers life more difficult in order to clear up unused memory, but Java is more programmer friendly because it’s already automatically done.
Also, switching languages is also made more difficult with specialized unique characteristics to a language. For instance, C++ has a scope operator, something which OP and Java do not have. New concepts from language to language might not take too much time to learn, but there's still a transition period required.
My conclusion to the article and to the question "how do the differences in the languages affect peoples' programming" is that each OOP language was created with a particular solution to some problem in mind. Smalltalk, for example, was the first complete OOP language and having everything as a object seemed to work for the ideal OOP language; however, Java's primitive types helped to abstract (one of the key concepts to learning a new language) some basic features so as to give some "free-bies" to inexperienced/unfamiliar with the OOP concepts coders.
Derek DeRaps' article compared some non-OOP languages in the mix as well and even took everything one step further with research on a programming assignment carried out in each of the languages. There were differences in runtime, memory usage, code length, and coding time required but the reliability came out to about the same. Therefore, my conclusion still stands that the OOP languages (and all languages) were constructed to solve certain problems. However, since not all of the problems have been solved under one language the existence of other languages is necessary until such a time. Depending on the characteristic you wish to optimize, a certain language could work better than others.
For discussion 2, I read an article called "Design Pattern (computer science)" on Wikipedia. The link to the article is: http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29. I also referenced "What Are Design Patterns?" (Link: http://www.developer.com/design/article.php/3325211)
Part 1)Question: What are the differences between creational, structural, and behavioral patterns?
Creational patterns control the creation of objects and in doing so they optimize the instantiations of objects.
Structural patterns deal with the relationships between entities. They make it easier to have large, structured programs through the careful composition of objects into groups.
Behavioral patterns improve the communication between entities. They increase flexibility and flow of communication between complex entities.
Part 2) I referenced Wikipedia at http://en.wikipedia.org/wiki/Low-Coupling_/_High-Cohesion_pattern:
Low-Coupling/High-Cohesion pattern is a functional pattern that aims to fulfill OO programming standards while also becoming easier to understand, program, and maintain.
The concept is two fold. Low-Coupling implies that the relationship between entities is as basic as possible with as few ties between the two entities. Whether it's a method in one object that is responsible for the overall communication between objects or one object inheriting for another, the lines of communication are not overbearing.
High-Cohesion is the amount of understanding and effectiveness with the amount of "lines" between entities.
Therefore, the total concept is to have as little as possible and do as much as possible. It's basically getting a lot of functionality with as little code/complexity as possible.
This interests me because I am not a huge fan of coding because a lot of the time the connections between objects results in a complex network of confusing code. This design pattern would reduce the connections between objects and would help me to understand the overall functionality of the program at a quick glance rather than studying code for hours on end.
It makes sense to me that it is necessary to carefully design the interaction between classes so that the functions that need to get done are done with as little complexity as possible. Sitting down and writing code without first spending time on design is definitely the best way to NOT use this pattern. In my own coding, I could use this principle by first sitting down and drawing out all of the interaction between classes and then optimizing the number of connections between classes so that low coupling is maintained.
My only qualm with this pattern is that it is easier to praise it and more difficult to put into effect. I will definitely always try to use this pattern because I just know I will end up looking at my own code months later and I will not be able to follow my own complex awkward way of thinking at the time that I first wrote the code.
For discussion 3, choose one of the following to post about:
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?
2. In detail, describe a feature of Squeak that you have found particularly useful. What is the feature? Why is it useful? How do you envoke it?
2. In order to code in the most effective way, I utilize the tools in the menus surrounding the Squeak interface. A couple of the tools that I use are in the Tools menu bar on the right side of a screen, the message names tool is particularly helpful to me. With it you can look up method names that you might want to use but you don't know how. It can be dragged from out of the Tools sidebar or you can press alt-shift-w.
The method finder tool is similar to the message names tool and can also be accessed from the side Tools menu bar.
To use the method finer, just type into the top pane or use an example to find a method in the system. Type receiver, args, and answer in the top pane with periods between the items. Ex: 3. 4. 7 –> produces +
This will tell you all of the method that use parameters in this fasion.
Lastly, the object catalog in the Widgets menu bar (on the bottom of the screen) gives a lot of objects that we have been using a lot in class organized by categories. The object catalog provides easy access to objects like books, clocks, watches, and other visual tools.
All of these instances of tools help to visually tie in all of the aspects of code before you have to look at the code.
Link to this Page