What is the MVC model and how can it lead to more efficent and organized code? In addition, what are some potential drawbacks to using the MVC model?
MVC stands for Model-View-Controller. The concept revolves around the logitical idea that what the user sees and what the program actually does are two entirely independent entities. There is no reason for either to rely on the other. Model represents the program; view represents the user interface; and the controller is the interactive element between the two involving passing information back-and-forth as well as typically handling events. This method allows for a particular section of the program to be overhauled without affecting the other portions at all. In terms of design this is a very strong pattern to follow because of its great flexibility.
The largest drawback by far is the extreme overhead of having three separate parts. Just about every signal or piece of data must go through all three parts in order to go from data to display. This especially gets complicated when a program involves one model-multiple views or one view-multiple models. Larger cases like this tend to create a controller that must handle many different possibilities. Either way, it shows that by complicating one portion at least one other part must become much larger to make up for the complexity.
Essentially the MVC model is in practice a great design practice, but a very poor technique in practice.
I disagree with you here. MVC (or decoupling the model from the view and controller) is actually quite a good technique. It can at times mean that there is a large amount of message passing, but the vast majority of the time this is not a problem.
What is refactoring and why would you want to do it?
Name one kind of refactoring and the problem it is supposed to solve.
SUnit is a unit testing suite used to assure individual pieces of a project are working correctly. It is used to sniff out the faulty components of a project and make finding bugs a lot easier.
Refactoring involves rewriting code in order to make it more readable, efficient or otherwise better, but not actually modifying its function. Often once a problem is solved, it is easy to go back and reconsider the "best" way of solving the problem. It is often touch to discover the "best" way off that bat, but becomes easier after working through the problem once or twice.
The 'Extract Class' method of refactoring takes a large, bloated class and breaks it into smaller components. The presentations give the example of breaking out a Person's credit card information into a separate class. More than readability, this opens up the ability for other classes to make use of certain functions, like the credit card information, in order to prevent writing similar code multiple times.
Jiasheng He's post introduced me to the Whiskey Browser which I've now started to use frequently. Once I found the System Browser the programming seemed to become easier. With Whisky Browser, I feel like I am even more comfortable using Squeak.
I have realized I was probably doing this since day one, but Robert Hutson's post really got me thinking as to the fact that the ability to mess around with objects before worrying about the code really helps. I guess I can compare it to using pseudocode before hacking out language-specific code. The more I use Squeak, these obvious features are some of the things that I like the most about the language/VM.
The biggest annoyance/problem that I have had so far with Squeak is the lack of an API or extensive Squeak material online. Coming from years of Java, I'm very accustomed to an in-depth API and an almost obscene amount of online help. Squeak's documentation is quite poor, but, unlike Java and many other languages, the function names are quite accurate as to their function. At first I was simply getting used to spending extra time looking through all of the available methods. After a few good hours of poking around the language and the browser, I noticed that the best way to figure out all of these classes is the mess around with the morphs already implemented in Squeak. As opposed to the Java and other programming classes I've taken, it is impossible to sit down and start on your homework. The best way to become good at Squeak is purely to spend hours each day "poking" around all of the most used morphs (TextMorph, ImageMorph, PasteupMorph, etc.) in Squeak. The few sites that I found helpful are the official Squeak Swiki (http://minnow.cc.gatech.edu/squeak) and of course good old fashioned Google. There are mixed tutorials across the Internet, but other than the swiki, there's not a single extensive site for Squeak help. The most useful feature I've found in Squeak for this is the Package Browser. By looking under certain groups Morphic/Basic, Kernel/Numbers for instance give a good idea of typical methods to look for. By searching through classes by category, it is easy to find Morphs based on what kind you are looking to create rather than trying to search through the Browser for random keywords.
Creational, structural, and behavioral patterns are three differnet kinds of design patterns that serve very distinct purposes. Creational patterns are used in relation to creating new objects, such as creating an abstract class that creates other classes called Factory classes (link). The second category, structural, deals with how classes work together. The capabilities of each class are untouched, and the methods in which they're managed do not change, but instead structual patterns bring multiple classes together in certain ways in order to produce greater abstraction or more understandable functionality. Last, behavioral patterns take the kind of structural relationships that are commonly used and abstracts them into various other classes that helps add certain types of auxiliary uses such as event listeners (link) and state patterns (link).
Looking at many of the patterns, the mediator pattern stood out because it is a pattern I had used during a previous project in 2335. We created several mediator classes that formed the backbone of our project. This helped greatly, in that, the project on either side of the mediator class could be developed entirely independently of what was being done on the opposite side. As stated on source #2, the mediator classes can only be used once for a specific purpose, but often do not need extensive modifications in order to adapt to an expanding project. The main advantage that originally interested me in this implementation was that it created a very centralized way of keeping all of the components of a project tied together, without worrying about directly tying the functional classes together. The mediator classes allowed the functional classes to worry about its actions, and the mediator classes could concentrate on all the necessary interconnections and relationships. This allowed for a much more productive group environment without the hassles of modifying each other's code in order to get everything working. The extra classes almost definately create a little extra overhead, but the advantages of these extra classes far outweighed the few minor problems.
Source: Baas, B. 2002. Ruby in the CS curriculum. J. Comput. Small Coll. 17, 5 (Apr. 2002), 95-103.
This article focuses on the inclusion of Ruby in a CS 1 class at a Texas University, but makes many good points on using Ruby for learning to correctly program, especially in introductory classes. The most obvious difference Baas shows is that Ruby, along with Perl, Python and others, are all scripting language. This is not especially helpful in programming projects due to the performance sacrifice., but does create a very good interactive feel to make small changes that are seen immediately, without recompiling dozens of files. Purely for educational sake, picking a language like Ruby that is less popular eliminates the risk of a language like Java or C++ being passed over because of students that have already been exposed to these more common languages. This fact helps for the sake of teaching, but, in terms of actual programming prowess,
Ruby also has many interesting features that balances its power and usability. Like Smalltalk, Java and plenty of other, Ruby is entirely object-oriented and forces the programmer into a much cleaner and more rigid design. Everything is an object, exactly like Smalltalk and Squeak, but does not require any kind of large virtual machine overhead. Instead, it runs with the simplicity of other interpreted languages like Perl and Python, gaining the ability to be extremely portable to any architecture that the interpreter has been created for. The syntax is easier to approach than Perl, but is not hindered by some of the intricacies, such as whitespace and capitalization, in Python. Ruby is a good balance between the power of compiled languages and the simplicity of scripting languages.
In reading the post by G. Stepanov, I realized that the use of Ruby solves all of the problems that C++, Java, Smalltalk, and Eiffel raised. Ruby is designed to be fully object-oriented and simplified which eliminates the learning curve of C++. The similar syntax problem in Java is also solved, as well as the need to teach full object-oriented techniques from the beginning. Ruby require knowledge of full OO programming, but does not demand it in every program the way in which Java does. Eiffel was not created with learning involved, this is a huge hindrance in starting off with any language. Ruby has a currently very active community and many published books/papers on the topic. Lastly, Smalltalk's strange syntax and virtual machine use makes introduction to the language very discouraging and difficult. Ruby is built on well-established syntax rules similar to Python and runs on a simple interpreter that can be run (and closed) at will.