The next thing that we will explore in the Jack language specification is the notion of classes. Now, the class is the most fundamental and basic combination unit in the Jack language. Likewise, in Java, C#, C++. Each class named Foo is stored in a separate jack file. And this file is compiled separately from all the other class files in your application. And we require that the class name will be the same as the file name, and we also require that the first character in the class name and the file name will be an uppercase letter. Now, here is the general skeleton of the class in Jack. It begins with a class name and then we have field, variable declarations, which are optional but if we have them, they will appear here. Then we have another set of zero or more static variable declarations. And finally, we'll have what I call the subroutine declaration. And by subroutine, I refer to constructors, methods, and functions. So they should appear at the end of the class declaration and typically they capture the bulk of the class contents. However, we have this syntactic requirement that filled in static variables if they exists in the class must appear before the subroutine declarations. Okay, what I'd like to do next is take a bit of a day version and talk a little bit about the semantics of classes and to which purposes do we use classes at to begin with. Well, we use them for numerous different purposes and there are causes in software architecture and software engineering that describe what is known as design patterns of classes and different purposes and morphologies of classes. But in my view there are two main sort of categories of classes, at least that's how I think about it. There are classes that provide functionality. And the good example of these classes is our OS math class, which as you see, the API here is just a library of commonly used mathematical functions. And anyone can use these functions at will and the library provides the implementation, hopefully provides an efficient implementation of this functions. And what is special about these kinds of classes is that they contain functions only. There are no fields, no constructors, no methods and obviously there are no object. And therefore, this class and similar classes are essentially libraries of or modules containing functions. So, that's one sort of mega category of classes. And then the other mega category, within which there are many more subcategories, are classes that represent what we sometimes call entities or objects. And examples of these classes that we saw already are fraction, list string, everyone of these classes is designed to represent instances of the class, right. Objects that are created and manipulated according to the class capabilities. And in Jack, if a class has at least one method, one or more methods, then it is bound to be a class that represents an entity and typically such a class will also contain fields and methods to represent the data of the entities and the operations that are allowable on these entities. And finally, classes that represent entities or objects can also have functions that if the programmer knows what he or she is doing, then these functions should better serve only for internal helper purposes, these are sometimes called in Java, I think private static methods. So for example, if you write a method that operates on an object, and in the process of doing so, you have to do some long, complex computation that repeats itself in several other methods, you may want to factor this computation outside, to a function that resides in the class and on the other subroutines in the class use it. So, that's perfectly okay you can create such helper functions for internal purposes. However, as a general advice that has nothing to do with this cause, you should remember not to expose these helper functions to the rest of the world, to other classes outside your particular class that is designed to represent objects. If you do want to create some functionality that is not related to objects of this class and may help other clients as well, you should take these functions and put them elsewhere you should put them in separate classes not in this one. So, the general advice is not to mix library functionality with object representation functionality in the same class. You should separate them. And once again, these are general software engineering propositions which are not directly related to this course. And in order to illustrate this principle, I will show an example that actually violates it. And this example is the fraction class that we saw earlier in the course. If you look at this class, you will see in this slide here, we have a constructor, a method called reduce, and a function called GCD. And the method that as I just described, it computes the great common divisor of two numbers, which happen to be the numerator and the denominator and then it uses the result for some purpose. Now, what's wrong with it? Well first of all, in terms of syntax and Jack's sanity and so on, everything's just fine. The compiler will happily translate this program, and it will work perfectly. But from an aesthetics design and practical matters, this is a bad solution because GCD is a very general function and it has lots of things to offer outside the context of fractions. In other words, other classes that do also all sorts of other things for instance with the prime numbers, would benefit from being able to access this GCD function. And therefore, it makes perfect sense to refactor this GCD code and put it in a separate class, and this class may well be the math class of our operating system, or your own math class, which is a library of mathematical functions. So, here's an example of two classes that are executive classes that I described before. Fraction represents an object and math is a library of mathematical operations. GCD being one of them. So this is a much better solution. It has many good benefits. One of them is that, the fraction class will be tighter and more focused. More to the point, it will deal only with fractions and nothing else and the math class is now extended or with additional functionality and now many other clients can use the GCD function, which before was buried within this fraction class. So what you see here is that, how should I put it? Well, object oriented languages are incredibly powerful and they have lots of expressive power. And in the wrong hands of programmers who are not well trained, they can lead to monstrous programs, which are impossible to extend and maintain. And these are programmers who don't follow these best practice advises. So, all of this really has nothing to do with nantu tetris, this was just a commercial designed to advise you that if you want to be a serious developer, you have to take some software architecture courses or at least one course or software design, design pattern and something like this, that will teach you how to design software correctly, all right. Moving along, a Jack application as we explained before in the course, is a collection of one or more Jack classes hopefully well designed. One of which must be named main. This class should have at least one function named main and main.main becomes the entry point of the entire application. I'm repeating this here for just for completeness because we discussed this before. And finally, I want to say a few words about the support library that comes with Jack, which is similar to the support library that comes with Java, at least in principle. And here's the very same code example that we used all along. And if I look carefully at this code I see that it has many calls to OS routines. And this is very natural in Jack as well as in other high level object oriented languages that work tightly with some operating system layer that surrounds them. Now, the purpose of the operating system is versatile. First of all, it is design to close various gaps between high level programming and the host hardware and peripheral devices like the key board, the screen, the mouse, the scanner, the printer, the camera, the microphone and so on and so forth. And indeed you see in this code example here that if you want to read something from the keyboard, you have an always routine who does it, keyboard got redeemed. And believe me, that writing this routine is a pain because you have to get into the keyboard and read the scan keys and turn and clicking on keys to integers and strings and so on. And you will discover that this is not simple when we develop the operating system towards the end of the course. But once again I promise that we will do it in the most elegant way possible, so it won't be that terrible. But as far as the high level programmer is concerned, he or she could not care less about all these gory details because the OS delivers this instruction nicely and elegantly. Another purpose of the OS is to provide efficient implementation of widely used functions like square root for example. And finally, we also want the operating system to represent efficiently commonly used obstruct data types like arrays, string, list and so on. In terms of implementation, the OS that accompanies Jack consist of eight classes, we will see them in the next slide. And once again, the whole concept is similar in spirit, I emphasize in spirit to the Java's standard class library. And the only difference between our class library and Java's class library is that our library contains eight classes and the Java's standard class library as of Java 8, contains I think more than 4,000 classes. And that's because Java is an industrial strength language. So you have to support so many things like networking and files and encryption and compression and multi threading and numerous other things. And of course we could have done the same with Jack but we didn't have to because it's not in the scope of the course, but they are similar in the sense that the Jack standard library is wide open and we can extend it anyway we want and we may do it in some advance courses if we ever have the energy to build them. So, as promised here is the description of the eight OS classes that supported Jack and if you want to read the complete OS API, you're welcome to look at the Nand to Tetris book in the website and the APIs available there. So with that we're done with this unit. And in the next unit, we'll complete the specifications of the Jack Language when we discuss methods.
