 Hello and welcome back to the second part of CS101x introduction to computer programming. In the first part of the course we have seen various constructs that are used to program in C++. In the second part of this course this being the first lecture of the second part we are going to move ahead and try to see a few more advanced features of programming in C++. Specifically in this lecture we are going to see a brief introduction to object oriented programming and we are going to have an look at structures as an example of objects in C++. Here is a quick recap of some of the relevant topics we have already studied earlier in the course. We have studied about the basic ingredients necessary for programming in C++. Specifically we have studied about various data types and the usage of variables, constants and arrays. We have seen how sequential and conditional statements are used in C++ and we have also seen how iterative constructs and functions are used in C++ programs. In this lecture we are going to discuss the basic idea of object oriented programming which is a very important paradigm of programming when you are trying to design complex software systems and we are also going to see a brief introduction to structures as an example of objects in C++. Some examples in this lecture are from the book An Introduction to Programming Through C++ by Abhiram Giranade published by McGraw Hill Education in 2014. All such examples are going to be indicated in the slides with the citation AGR. Now this particular example that we are going to discuss now is motivated by the text AGR book. Suppose we want to design a slightly complex program which is going to manage the check out return and claim of books by different patterns in a small library. So how does this system work? Every pattern of the library is going to have a unique numerical ID. Every book in the library is going to have a unique accession number. A pattern can check out a book and she can check out up to 3 books at any time. If pattern X has not already checked out 3 books, she can claim one book and at most one book which might have already been checked out by another pattern Y. What does this mean? If pattern X places a claim for a book that is currently checked out by Y, it means that when pattern Y returns the book, it is going to be held for pattern X and not lent to others. And of course a pattern can return a book that she has checked out sometime earlier and let us say that this is a fairly benevolent small library. There are no late charges for returning books late. So how are we going to implement the information management system for keeping track of checkouts, claims and returns for the small library? Should we jump into writing codes straight away and then keep adding variables or arrays and functions as and when needed? Well, if we try to do that, the first thing that we have to realize is that for each book, there are several kinds of information that I must store in my information management system. Specifically, for each book, I need to store the title and the authors. Now the title is going to be a string, so I need a character array for that. The names of authors are also going to be strings and in fact, if there are multiple authors, I could separate them by commas and store them as the same string. For each book, I also need to store the price in Indian rupees and I could have a double variable for each book for this purpose. Similarly, I could have an integer variable for each book which stores the accession number of the book. I could have a Boolean variable for the book which stores its checkout status and I could also have an integer variable for each book which stores the unique ID of any claimant for that book. Similarly, for each pattern, I need two character arrays, one to store the name and one to store the address. I need an integer variable to store the unique ID of the pattern. I need another integer variable to store the number of books checked out by the pattern and finally, I need an integer variable to store the accession number of a book that this pattern might claim. As I have said earlier, each pattern is allowed to claim only one book at a time. So, we have only one integer to store the claim books accession number. Well, now if our library has 1000 books, how am I going to organize all of this information? Well, one alternative could be to use different 1000 sized arrays where each array stores one kind of information. So, for example, I could have a 1000 sized array storing the book titles. Every element in this array will give me the title of a book, but since the title of a book is a string, every element in this array must be a character array in itself. Similarly, I could have a 1000 sized array storing the author's names and every element in this array must give me the names of the authors of a particular book and since the names of the authors are going to be strings, they need to be stored in a character array. Similarly, I could have a 1000 sized array named price where an element of that array gives me the price of a book and similarly, I could have 1000 sized arrays named accession number, checkout status and claimant ID where an element of each of these arrays would give me the accession number or the checkout status or the claimant ID respectively of a book in the library. Well, if I organize the information like this, perhaps it is manageable. I have six different arrays each of size 1000 and each of possibly different data types, but you would certainly agree that it is not natural to split information about the same book in six different arrays and let's see what kind of a situation might arise if I did indeed store information about the same book in six different arrays. Now, since the information about the same book is stored in the array title and also in the array price and also in the array accession number, how will I find out whether the book whose title is stored in the array book title at a particular index? How will I find out the price of that book? How will I find out the accession number of that book? So, one way to do this might be to say that let us store the information about a book at the same index in all the arrays. So, the fifth element or in this case, it's actually the sixth element since each array is going to start its index from 0. So, the sixth element of all of the arrays title, author, price, accession number, check out status and claimant ID must refer to the same book. They must basically give different kinds of information about the same book. So, this might be one way that we can correlate information stored in this different arrays for the same book. Now, suppose somebody asks that what is the unique ID of the claimant for the book with accession number 1, 2, 3, 4, 5, 6. Now, note that the claimant information is stored in one array, the accession number is stored in another array. So, how would we go about answering this question? Well, we will first have to find an index such that the array accession number at that index has the value 1, 2, 3, 4, 5, 6, whatever we are searching. And then, we have to use that index to access the corresponding element of the claimant ID array. Now, as you would agree with me that this is an unnecessarily convoluted reasoning, I am searching one array to match the accession number, then using the index from that array to access another array to find out the ID of the claimant. So, is there a better way to go about doing this? Well, in trying to answer this question, let us first ask that would it be nice if we could do the following, if we could group all information about a book into a book entity and then have an array of these book entities. So, once we search this array and find an entity whose accession number is 1, 2, 3, 4, 5, 6, since all information about a book is stored in the same entity, we could simply read off the claimant information from this entity which is an element of this array. And why just group information about book entities? We could also group information about patterns into pattern entity and then have an array of these pattern entities. So, how do we do this in C++? C++ actually provides this construct called structures to group a set of variables of possibly different data types together. So, for example, here I am grouping different variables which are storing different kinds of information about a book. I am grouping all of them together into one entity which I have now declared through the C++ keyword called struct. So, this keyword says that now I am grouping together variables, arrays of possibly different data types because all of them contain information about a particular entity. So, that's what the struct keyword says. Book is the name of the structure type that we are defining and this is just like the name of any other data type like int or char. So, for example, I could define variables of type book. I could define arrays of type book as we will shortly see. These different things inside the struct definition, these are the things that basically store the different kinds of information about the book. These are also called members of the structure book and note that members could be arrays of other data type or simply variables of other data type. And this other data type that we are talking about need not be primitive data types, they could indeed be other structured data types. And we will see later in the course how within a structure I could have variables or arrays of another structured data type. Now, a member of the structure has two parts. It is a member type and a member name. So, here price is the name of a member of data type double. And as I just said, we could declare variables of this structure type book. So, here I am declaring two variables, my choice and your choice of structure type book. And note the similarity with declaring two variables, my int and your int of data type int. Similarly, I could declare an array of type book. So, here I am declaring an array called library shelf of size 1000, where each element in this array is of structure type book. And note the similarity with declaring an integer array roll numbers of size 1000. And just like we have grouped information about a book together in a structure. We could also group information about pattern in a structure. And this is very similar to what we have done for books, except that here I am storing the names address, the unique idea of a pattern, the number of books checked out by the pattern, and the accession number of any book claimed by the pattern. So, what is the overall design philosophy that we are appealing to over here? We are saying that well, when you are trying to design a complex software system, first identify the entities which could be physical or conceptual entities that are involved in the working of the system. For example, in our example, they were books and patterns. And these entities are also going to be called objects. And then you can think of the system functionality in terms of operations on and interactions between these objects. For example, pattern and object could be checking out a book which is another object. Similarly, pattern and object could be claiming a book which is another object. And what we will see later in the course that in this paradigm, what we often try to do is that we try to abstract away or hide details that are not necessary for a particular operation. We will look at more examples of abstraction or hiding details later in the course. So, in the object-centered design philosophy that we are talking about over here, we are going to implement a system modulally by focusing on these objects or entities. They are the first class citizens in this design paradigm. And we are also going to understand how they interact with each other. And we are going to build interfaces for these entities that enables these interactions. And this in one slide is what object-oriented programming is about. Clearly, you can see that objects play a very central role in this paradigm of programming. Now what is an entity or object? It could contain information specific to an object. So, this information could be of some fixed type which usually doesn't change as the objects interact. This could be the name of a pattern or the title of a book. It could also be state information which changes as the objects interact, like the checkout status of a book or the number of books checked out by a pattern. Each object must have unambiguous and very well-defined boundaries. We must be very clear about what information is stored as part of what object. For example, when a pattern claims a book, there are two parts of the information with respect to this claim. Where is this information going to be stored? We have to be very clear about where it's going to be stored. For example, we can say the claim inside it will be stored in the book object. And the claimed book's accession number will be stored in the pattern object. Ideally, we should allow objects to interact only through very well-defined interfaces. And this allows hiding unnecessary details of an object from the programmer. For example, when a pattern is trying to check out a book by specifying its accession number, do we really need to access the title of the book or the name of the author or its price? If we don't, then the programmer should not try to access these details of the book object when he or she is trying to implement the checkout functionality for a pattern. So, this is achieved through what we call abstraction or data encapsulation, which will be covered in much more detail later in the course. So, in this lecture, we basically saw some motivation for object-oriented programming and we also saw a brief introduction to structures as an example of objects in C++. Thank you.