Machine language is the set of instructions that a particular model of CPU understands. By definition, every program that a computer executes is in the form of its machine language, but that doesn't mean it was written that way. The instructions in a machine language are trivially simple, which means machine language programs require many instructions to accomplish even a simple processing task. Programming in machine language is therefore a tedious task that is avoided whenever possible.
You might wonder: If machine language is the language the CPU understands, how can one program any other way? One can write in another programming language that is easier to use, then translate the program into the machine language of the CPU used to execute the program. These easier-to-use programming languages are called "high-level languages" because they are at a high level of abstraction from the actual machine hardware. The process of translating a high-level language into a machine language is called compilation.
For example, suppose that a programmer needs to write a loan application program for a bank. The bank will run this program on its loan officer's computer, which uses an Intel Pentium IV processor. The programmer doesn't want to write directly in the Pentium IV machine language, determines that the high-level language Visual Basic is the best choice for this project, and so writes the program in the Visual Basic language.
When a program is in the form of a high-level language, it is called source code, because it is the source of the machine language program that is actually executed. The programmer compiles the source code using the Visual Basic compiler, which translates the program into the Pentium IV machine language. In the form of machine language, the program is known as machine code, or the executable.
The compiler is the central tool of the programmer. Having the compiler places the programmer on a higher level of abstraction. The programmer can, to a great extent, ignore the hardware and concentrate on solving the problem at hand. Before solving the problem, though, the programmer must pick a programming language in which to solve the problem.
The original way of making programs, procedural programming, simply defines the control flow necessary to solve a task, using procedures to divide the source code into functional units. Because procedural programs are similar to the algorithms they implement, this style of programming is considered easier for the beginning programmer to understand. However, pure procedural programming has weaknesses.
Its straightforward "list the steps to solve the problem" model worked well when most programs simply consumed input and produced output. Today, most programs are interactive; they sit waiting for the user to tell them what happens next. The procedural paradigm does not match up well with this style of program. Also, procedural programs are often "loose" with data, sharing the data among all parts of the program. Allowing unfettered access to data has problems.
In object-oriented programming, instructions are grouped together with the data they operate on. To understand what this means, consider the student records office at a typical university. The registrar is the official in charge of safeguarding students' official records and making any applicable changes to those records. Students come to the registrar and fill out forms for their various requests, such as having a transcript sent to another school, updating the student's address, or changing the student's enrollment in the coming semester.
The students have no direct access to the records themselves; they may only hand their forms to the registrar, who then executes the request, which results in returned copies of records, changes in the files, or whatever the request might have been. This situation illustrates the key principle of object-oriented programming, information hiding, which occurs when data is placed out of direct reach of the data's users. Here, the users are the students, the data are the records, and the registrar lies between them.
Information hiding has many benefits, the first of which is that it maintains the integrity and security of the data. Consider the problems that would occur if the students had direct access to the file room. They might file paperwork that was incorrectly completed because it would not have been reviewed by the registrar. Furthermore, each student would have access to all student files, not just his or her own, a serious security and privacy concern.
By requiring all requests to go through the registrar, all paperwork can be checked for accuracy before filing, and all students can be required to show identification before they are provided copies of their records, assuring security and privacy.
Another benefit is the separation of the interface from implementation. The forms the students must fill out for their requests are the interface of the records system; the forms are all that the students see of the records office. The implementation is the method used to store the files. The files could be stored on paper in cabinets, on microfilm, in a computer database system, or even in different formats for different records.
Because the interface and implementation are separate, the students do not need to know how the records are actually stored. Furthermore, the records office can change the filing system at any time without affecting the services to the student, as long as the forms the students use do not change.
A final benefit is reuse. Suppose that instead of only one records office for the entire university, each individual school at the university had its own. If the same forms are used at all records offices throughout the campus, a student who began in the School of Humanities but later transferred to the School of Mathematics will understand how to make requests of the new school's records office because the interface is the same at both.
The object-oriented programming paradigm gives all these benefits. Instructions and data that logically belong together are kept together, which allows parts of code to be reused in other programs without a lot of trouble. Certain procedures act as gatekeepers - like our registrar - which keeps the data secure. The interface is kept separate from the implementation so that, if a better algorithm for some problem is found, a new piece of program can be substituted without disturbing the rest.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Raymond Harris at 02132011
1. The camera model and similar techniques
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.
Partners: Damenmode