Computer programming: What is object-oriented language? | lynda.com overview




This computer programming overview introduces and explores object-oriented language. Watch more at

This specific tutorial is just a single movie from chapter twelve of the Foundations of Programming: Fundamentals course presented by lynda.com author Simon Allardice. The complete Foundations of Programming: Fundamentals course has a total duration of 2 hours and 47 minutes, and covers creating small programs to explore conditions, loops, variables, and expressions; working with different kinds of data and seeing how they affect memory; writing modular code; and how to debug, all using different approaches to constructing software applications

Foundations of Programming: Fundamentals table of contents:

Introduction
1. Programming Basics
2. Core Programming Syntax
3. Variables and Data Types
4. Writing Conditional Code
5. Modular Code
6. Iteration: Writing Loops
7. More About Strings
8. Collections
9. Programming Style
10. Input and Output
11. When Things Go Wrong
12. Introduction to Object Orientation
13. Advanced Topics
14. Exploring the Languages
Conclusion

source

20 thoughts on “Computer programming: What is object-oriented language? | lynda.com overview”

  1. A few nits and one more substantive observation about an excellent introduction.

    First, the nits. In an introductory video like this, I prefer to introduce newcomers to the actual vocabulary used in the field rather than "simpler" terms that only create confusion later. Programmers find it most clear to describe a specific object as an "instance" of a class. Next, each element of an object's internal state is called an "instance variable". A "property" is something else entirely, and the difference matters. A "property" is a named value associated with an object, but not part of it. In order to change the value of an "instance variable", the object itself must be changed. In order to change the value of a "property", no change to the object is needed. An instance variable of an automobile might be a "transmission". A property of the same automobile might be "license number".

    A more substantive observation regards the topic of comparing various languages and how they accomplish object orientation. A competent programmer who understands the "big ideas" of object-orientation can write object-oriented code in ANY language. Several modern languages provide "object oriented" extensions that add "syntactic sugar" to simplify this task. For example, php was created as a scripting language, and provides its object oriented behavior through language extensions. The result is usually clumsy in comparison to languages created as object-oriented from the beginning.

    The main "big ideas" of object oriented are that an "object" is a dictionary — a collection key-value bindings — with a specific memory address. A "method" is a function that acts on that dictionary. The BIG difference between object-oriented and procedural code is that a method is called INDIRECTLY. The class of an instance contains something called a "method dictionary". This is a dictionary that maps the NAME of a method (called it's "selector") to the function that implements that method (called it's "body" in some languages).

    So, in response to some of the comments below, the reason why O-O can be easier than procedural code is that a given method ("printOn") can be implemented by multiple classes ("Document", "Email", "Drawing" …). The actual code that renders an instance of document on a particular printer can be (and usually is) different from the code that renders a drawing. From the outside, a programmer writing a user interface doesn't need to know or care WHAT is being printed — only that the instance implements "printOn". THAT encapsulation is the reason why object-oriented is so appealing.

    Finally, again in comparing languages, a fundamental difference has to do with whether the classes, methods, and other components of an application (its "metastructure") are themselves accessible to the application. In many languages, they are not. This was a significant obstacle to acceptance of the first versions of C++. Other languages (like Java) are "reflective", so that a method of an object can, at runtime, have access to the its class, other methods, and so on. Some languages (like Smalltalk) are "causally reflective", so that a change to the class causes a desired change to the behavior of instances of that class (and the classes that inherit from it).

    Again, kudos for a very accessible introduction to this very deep field.

  2. Glad to not watch another vid telling about car being class color being attrib and drive being method and just that and we are lik Wtf!!
    But sir you explained it so much better than anyone could have explained to me .

  3. Damn! I've been googling for a year on what OOP language really is and all answers I've found are either too technical (for a newbieee like me) or vague.. And then I found this video! Great job!

  4. "The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."

Leave a Reply