• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Fundamentals of Object-Oriented Programming
The goals of this tutorial are to guide you through the terminology of object-orientedprogramming (OOP) and to give you an understanding of the importance of object-oriented concepts to programming. Many languages, such as C++ and MicrosoftVisual Basic, are said to "support objects," but few languages actually support all theprinciples that constitute object-oriented programming. C# is one of theselanguages: it was designed from the ground up to be a truly object-oriented,component-based language. So, to get the absolute maximum out of this book, youneed to have a strong grasp of the concepts presented here.I know that conceptual tutorials like this are often skipped over by readers who wantto dive into the code right away, but unless you consider yourself an "object guru," Iencourage you to read this tutorial. For those of you only somewhat familiar withobject-oriented programming, you should reap benefits from doing so. Also, keep inmind that the tutorials that follow this one will refer back to the terminology andconcepts discussed here.As I've said, many languages claim to be object-oriented or object-based, but fewtruly are. C++ isn't, because of the undeniable, uncircumventable fact that its rootsare deeply embedded in the C language. Too many OOP ideals had to be sacrificed inC++ to support legacy C code. Even the Java language, as good as it is, has somelimitations as an object-oriented language. Specifically, I'm referring to the fact thatin Java you have primitive types and object types that are treated and behave verydifferently. However, the focus of this tutorial is not on comparing the faithfulness of different languages to OOP principles. Rather, this tutorial will present an objectiveand language-agnostic tutorial on OOP principles themselves.Before we get started, I'd like to add that object-oriented programming is muchmore than a marketing phrase (although it has become that for some people), a newsyntax, or a new application programming interface (API). Object-orientedprogramming is an entire set of concepts and ideas. It's a way of thinking about theproblem being addressed by a computer program and tackling the problem in a moreintuitive and therefore more productive manner.My first job involved using the Pascal language to program the box-office reportingand itinerary applications for Holiday on Ice. As I moved on to other jobs and otherapplications, I programmed in PL/I and RPG III (and RPG/400). After a few moreyears, I started programming applications in the C language. In each of theseinstances, I was easily able to apply knowledge I had learned from prior experience.The learning curve for each successive language was shorter regardless of thecomplexity of the language I was learning. This is because until I startedprogramming in C++, all the languages I had used were procedural languages thatmainly differed only in syntax.However, if you are new to object-oriented programming, be forewarned: priorexperience with other non-object-oriented languages will not help you here! Object-oriented programming is a different way of thinking about how to design andprogram solutions to problems. In fact, studies have shown that people who are newto programming learn object-oriented languages much more quickly than those of uswho started out in procedural languages such as BASIC, COBOL, and C. Theseindividuals do not have to "unlearn" any procedural habits that can hamper their
 
understanding of OOP. They are starting with a clean slate. If you've beenprogramming in procedural languages for many years and C# is your first object-oriented language, the best advice I can give you is to keep an open mind andimplement the ideas I'm presenting here before you throw up your hands and say, "Ican fake this in [insert your procedural language of choice]." Anyone who's comefrom a procedural background to object-oriented programming has gone through thislearning curve, and it's well worth it. The benefits of programming with an object-oriented language are incalculable, both in terms of writing code more efficiently andhaving a system that can be easily modified and extended once written. It just mightnot seem that way at first. However, almost 20 years of developing software(including the past 8 with object-oriented languages) have shown me that OOPconcepts, when applied correctly, do in fact live up to their promise. Without furtherado, let's roll up our sleeves and see what all the fuss is about
Everything Is an Object
In a true object-oriented language, all problem domain entities are expressedthrough the concept of objects. (Note that in this book I'll be using the Coad/Yourdondefinition for "problem domain"-that is, that a problem domain is the problem you'reattempting to solve, in terms of its specific complexities, terminology, challenges,and so on.) As you might guess, objects are the central idea behind object-orientedprogramming. Most of us don't walk around thinking in terms of structures, datapackets, function calls, and pointers; instead, we typically think in terms of objects.Let's look at an example.If you were writing an invoicing application and you needed to tally the detail lines of the invoice, which of the following mental approaches would be more intuitive fromthe client's perspective? -Non-object-oriented approach I'll have access to a data structure representing aninvoice header. This invoice header structure will also include a doubly linked list of invoice detail structures, each of which contains a total line amount. Therefore, toget an invoice total, I need to declare a variable named something liketotalInvoiceAmount and initialize it to 0, get a pointer to the invoice headerstructure, get the head of the linked list of detail lines, and then traverse the linkedlist of detail lines. As I read each detail line structure, I'll get its member variablecontaining the total for that line and increment my totalInvoiceAmount variable.Object-oriented approach I'll have an invoice object, and I'll send a message to thatobject to ask it for the total amount. I don't need to think about how the informationis stored internally in the object, as I had to do with the non-object-oriented datastructure. I simply treat the object in a natural manner, making requests to it bysending messages. (The group of messages that an object can process arecollectively called the object's interface. In the following paragraph, I'll explain whythinking in terms of interface rather than implementation, as I have done here, is justifiable in the object-oriented approach.)Obviously, the object-oriented approach is more intuitive and closer to how many of us would think our way through a problem. In the second solution, the invoice objectprobably iterates through a collection of invoice detail objects, sending a message toeach one requesting its line amount. However, if what you're looking for is the total,you don't care how it's done. You don't care because one of the main tenets of object-oriented programming is encapsulation-the ability of an object to hide its
 
internal data and methods and to present an interface that makes the importantparts of the object programmatically accessible. The internals of how an objectcarries out its job are unimportant as long as that object can carry out that job. Youare simply presented with an interface to the object, and you use that interface tomake the object perform a given task on your behalf. (I'll further explain theconcepts of encapsulation and interfaces later in this chapter.) The point here is thatprograms written to simulate the real-world objects of the problem domain are mucheasier to design and write because they allow us to think in a more natural way.Notice that the second approach required an object to perform work on your behalf-that is, to total the detail lines. An object doesn't contain data only, as a structuredoes. Objects, by definition, comprise data and the methods that work on that data.This means that when working with a problem domain we can do more than designthe necessary data structures. We can also look at which methods should beassociated with a given object so that the object is a fully encapsulated bit of functionality. The examples that follow here and in the coming sections help illustratethis concept.NOTEThe code snippets in this chapter present the concepts of object-orientedprogramming. Keep in mind that while I present many example code snippets in C#,the concepts themselves are generic to OOP and are not specific to any oneprogramming language. For comparison purposes in this chapter, I'll also presentexamples in C, which is not object-oriented.Let's say you're writing an application to calculate the pay of your new company'sonly employee, Amy. Using C, you would code something similar to the following toassociate certain data with an employee: -struct EMPLOYEE{char szFirstName[25];char szLastName[25];int iAge;double dPayRate;};Here's how you'd calculate Amy's pay by using the EMPLOYEE structure: -void main(){double dTotalPay;struct EMPLOYEE* pEmp;pEmp = (struct EMPLOYEE*)malloc(sizeof(struct EMPLOYEE));if (pEmp){pEmp->dPayRate = 100;strcpy(pEmp->szFirstName, "Amy");strcpy(pEmp->szLastName, "Anderson");pEmp->iAge = 28;
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...