Part IV - Object Oriented Programming in JavaScript

Learning Objectives

  1. What version of JavaScript is used in this text, and why
  2. Global (simple) object creation in Java
  3. The nature of objects as property maps
  4. JSON and how to serialize an object with JSON
  5. How to implement and use Constructor Functions
  6. What are protocols, and how do protocol chains work
  7. How to use the DOM to find program elements such as Constructor Functions
  8. How to use Constructor Functions to reconstruct objects
  9. JavaScript scoping and closure
  10. Models for JavaScript objects

The procedural concepts of JavaScript were covered were covered in Chapter 8. These procedural aspects at least appeared to be consistent with other, more common Procedural (or Imperative) and Object-Oriented Programming (OOP) languages.

In some ways, though, JavaScript may already seems strange to the reader. For example, as was previously pointed out, JavaScript has characteristics that are not Procedural; JavaScript has true lambda functions (as opposed to languages like C# and Java that use lambda functions as syntactic sugar to hide other language constructs), and can be used as a Functional language. Functional programming is often a source of confusion to novices just getting used to JavaScript. In addition, arrays are not primitive data structures, where elements are accessed using a base address and index. In JavaScript, arrays are hash maps, and the index numbers are actually keys. This makes accessing of elements in an array seem strange or almost wrong to some programmers. Finally, JavaScript dynamic typing goes against everything most programmers learned in their first programming class, where all types are statically typed.

But perhaps the strangest concept in JavaScript is its Object paradigm, and that is what will be covered in this chapter. It is not at all like the Object paradigm built into more common OOP languages such as Java/C#/C++.

To start, the reader should be aware of the basic definition of an object, which is that objects are defined as collections of data elements and behaviors. This definition is true of more common OOP languages such as Java/C#/C++, and JavaScript.

Languages such as Java/C#/C++ then refine the definition so that a type used for an object definition is statically defined at compile time. The new operation in these languages then means to instantiate (or create a completed final instance) of that object in memory. The definition of that object in memory then never changes.

Language constructs such as the Java interface go a long way towards alleviating some of the worst effects of this static model and made a true abstract definition in the language without the C++ multiple inheritance confusion. This is why interfaces are so successful in making a better object model in Java than C++. But the fact remains that abstract types (interfaces) and classes are always statically defined in Java/C#/C++, and the new operator instantiates a static, final copy of the object.

JavaScript takes the definition of an object as collection of data elements and behaviors, and then uses a completely different view of how data elements and behaviors are defined. This view is not wrong (as some Java/C#/C++ programmers would believe), but it is at odds with the more traditional view of OOP languages. And until this view is understood and accepted for its own merits, it will appear wrong to programmers using an invalid cognitive view of JavaScript objects.

The purpose of this chapter is to explain the JavaScript view of objects. It will present this view with no reference to the view of objects from other languages, as to try to bring in an understanding of how objects are treated in a language like Java is much more a hindrance than a help. A reader with no Object-Oriented-Programming background is likely at an advantage to someone who feels they really grok Java.

The part will be divided as follows.

Chapter 16 will cover the specifications for the JavaScript, as defined by the European Computer Manufacturers Association (ECMA) and discuss why this book is based on JavaScript 5 (or ECMA 5) instead of JavaScript 6 (ECMA 6+) or higher,

Chapter 17 will describe in more detail why JavaScript is hard for programmers coming from other languages to understand.

Chapter 18 will look at basic objects in JavaScript. The section will cover associative arrays and give a more correct model of what an array is in JavaScript. It will then show how objects in JavaScript are property maps, and not instances of classes as in a class-based OOP. Finally, it will cover JavaScript Object Notation (JSON) format, which is a way to represent JavaScript objects externally.

At the end of this part, the reader should understand the object model that will be used in this text, and that will be used in the next chapter.

Licenses and Attributions

Speak Your Mind