Object Oriented Programming Quotes

Object-oriented programming offers a sustainable way to write spaghetti code. It lets you accrete programs as a series of patches.

Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.

All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables.

PHP as an object oriented programming language should be judged by how well it does the job, not on a preconceived notion of what a scripting language should or shouldn't do.

Armstrong: I think the lack of reusability comes in object-oriented languages, not in functional languages. Because 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.

Here is a minimal list of the things that every software professional should be conversant with: • Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books. • Design principles. You should know the SOLID principles and have a good understanding of the component principles. • Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design. • Disciplines. You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming. • Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables. Continuous

As usual, though, if you find yourself running into a wall, stop running into a wall!

One was how computers could be networked; the second was how object-oriented programming worked.

But while you can always write 'spaghetti code' in a procedural language, object-oriented languages used poorly can add meatballs to your spaghetti.

var person = {name: "John",                surname: "Smith",                address: {                  street: "13 Duncannon Street",                  city: "London",                  country: "United Kingdom"                }};

The most powerful kind of code constructs other code that has been bundled with just the right amount of curated data; such a bundle is not just a “function pointer” but a closure (in a functional language) or an object (in an object-oriented language).

I grow little of the food I eat, and of the little I do grow I did not breed or perfect the seeds. I do not make any of my own clothing. I speak a language I did not invent or refine. I did not discover the mathematics I use. I am protected by freedoms and laws I did not conceive of or legislate, and do not enforce or adjudicate. I am moved by music I did not create myself. When I needed medical attention, I was helpless to help myself survive. I did not invent the transistor, the microprocessor, object oriented programming, or most of the technology I work with. I love and admire my species, living and dead, and am totally dependent on them for my life and well being.

Every night, millions of Americans spend their free hours watching television rather than engaging in any form of social interaction. What are they watching? In recent years we have seen reality television become the most popular form of television programming. To discover the nature of our current “reality,” we might consider examples such as Survivor, the series that helped spawn the reality TV revolution. Every week tens of millions of viewers watched as a group of ordinary people stranded in some isolated place struggled to meet various challenges and endure harsh conditions. Ah, one might think, here we will see people working cooperatively, like our ancient ancestors, working cooperatively in order to “win”! But the “reality” was very different. The conditions of the game were arranged so that, yes, they had to work cooperatively, but the alliances by nature were only temporary and conditional, as the contestants plotted and schemed against one another to win the game and walk off with the Grand Prize: a million dollars! The objective was to banish contestants one by one from the deserted island through a group vote, eliminating every other contestant until only a lone individual remained—the “sole survivor.” The end game was the ultimate American fantasy in our Age of Individualism: to be left completely alone, sitting on a mountain of cash! 　　While Survivor was an overt example of our individualistic orientation, it certainly was not unique in its glorification of rugged individualists on American television. Even commercial breaks provide equally compelling examples, with advertisers such as Burger King, proclaiming, HAVE IT YOUR WAY! The message? America, the land where not only every man and every woman is an individual but also where every hamburger is an individual! 　　Human beings do not live in a vacuum; we live in a society. Thus it is important to look at the values promoted and celebrated in a given society and measure what effect this conditioning has on our sense of independence or of interdependence

David Parnas, whose paper was one of the origins of object-oriented concepts, sees the matter differently. He writes me: The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. The result is that people do bad designs with these languages and get very little value from them. If the value is small, it won't catch on.

More recently, a new generation of languages has begun to emerge. These languages—Small-Talk, C++, Java—are object-oriented. They treat a data structure—for instance, a picture to be drawn on the screen—as an “object” with its own internal state, such as where it is to be drawn or what color it is. These objects can receive instructions from other objects. To understand why this is useful, imagine that you are writing a program for a video game involving bouncing balls. Each ball on the screen is defined as a different object. The program specifies rules of behavior that tell the object how to draw itself on the screen, move, bounce, and interact with other objects in the game. Each ball will exhibit similar behavior, but each will be in a slightly different state, because each will be in its own position on the screen and will have its own color, velocity, size, and so forth.

The most important advantage of an object-oriented programming language is that the objects—for instance, various objects in a video game—can be specified independently and then combined to create new programs. Writing a new object-oriented program sometimes feels a bit like throwing a bunch of animals into a cage and watching what happens. The behavior of the program emerges, as a result of the interactions of the programmed objects. For this reason, as well as the fact that object-oriented languages are relatively new, you might think twice about one for writing a safety-critical system that flies an airplane.

which a drawing imported into a text document can no longer be altered, but must be changed in the original graphics program and reintroduced into the text document.) Out of the box the Star was multilingual, offering typefaces and keyboard configurations that could be implemented in the blink of an eye for writing in Russian, French, Spanish, and Swedish through the use of “virtual keyboards”—graphic representations of keyboards that appeared on screen to show the user where to find the unique characters in whatever language he or she was using. In 1982 an internal library of 6,000 Japanese kanji characters was added; eventually Star users were able to draft documents in almost every modern language, from Arabic and Bengali to Amharic and Cambodian. As the term implied, the user’s view of the screen resembled the surface of a desk. Thumbnail-sized icons representing documents were lined up on one side of the screen and those representing peripheral devices—printers, file servers, e-mail boxes—on the other. The display image could be infinitely personalized to be tidy or cluttered, obsessively organized or hopelessly confused, alphabetized or random, as dictated by the user’s personality and taste. The icons themselves had been painstakingly drafted and redrafted so they would be instantaneously recognized by the user as document pages (with a distinctive dog-eared upper right corner), file folders, in and out baskets, a clock, and a wastebasket. Thanks to the system’s object-oriented software, the Star’s user could launch any application simply by clicking on the pertinent icon; the machine automatically “knew” that a text document required it to launch a text editor or a drawing to launch a graphics program. No system has ever equaled the consistency of the Star’s set of generic commands, in which “move,” “copy,” and “delete” performed similar operations across the entire spectrum of software applications. The Star was the epitome of PARC’s user-friendly machine. No secretary had to learn about programming or code to use the machine, any more than she had to understand the servomechanism driving the dancing golf ball to type on an IBM Selectric typewriter. Changing a font, or a margin, or the space between typed lines in most cases required a keystroke or two or a couple of intuitive mouse clicks. The user understood what was happening entirely from watching the icons or documents move or change on the screen. This was no accident: “When everything in a computer system is visible on the screen,” wrote David Smith, a designer of the Star interface, “the display becomes reality. Objects and actions can be understood purely in terms of their effects on the display.

Because writing teaches writers to write,

In Python, practicality often beats aesthetics.

JavaScript has a very powerful object model, but one that is a bit different than the status quo object-oriented language. Rather than the typical class-based object-oriented system, JavaScript instead opts for a more powerful prototype model, where objects can inherit and extend the behavior of other objects. What

JavaScript doesn’t have a classical object-oriented model, where you create objects from classes. In fact, JavaScript doesn’t have classes at all. In JavaScript, objects inherit behavior from other objects, which we call prototypal inheritance, or inheritance based on prototypes.

pdb also includes a postmortem function (pdb.pm()) that you can run after an exception occurs, to get information from the time of the error. See

give people a tool, and they’ll code for a day; teach them how to build tools, and they’ll code for a lifetime. This

In the Python way of thinking, explicit is better than implicit, and simple is better than complex.1

Besides directory paths on Windows, raw strings are also commonly used for regular expressions

a raw string cannot end in an odd number of backslashes.

This description requires elaboration when the value and the slice being assigned overlap: L[2:5]=L[3:6], for instance, works fine because the value to be inserted is fetched before the deletion happens on the left.

In general, you can define collector modules that import all the names from other modules so they’re available in a single convenience module.

Because using classes well requires some up-front planning, they tend to be of more interest to people who work in strategic mode (doing long-term product development) than to people who work in tactical mode (where time is in very short supply).

remember that generator functions simply return objects with methods that handle next operations run by for loops at each level, and don’t produce any results until iterated; and

that’s why we need recursion here: the number of nested loops is arbitrary, and depends on the length of the sequence permuted:

polymorphism means that the meaning of an operation depends on the object being operated on.

As we get deeper into Python classes, though, keep in mind that the OOP model in Python is very simple; as we’ve seen here, it’s really just about looking up attributes in object trees and a special function argument.

Although we could implement all class behavior as method functions, operator overloading lets objects be more tightly integrated with Python’s object model.

Common practice dictates that overloaded operators should work the same way that built-in operator implementations do.

On the other hand, you might decide to use operator overloading if you need to pass a user-defined object to a function that was coded to expect the operators available on a built-in type like a list or a dictionary.

the attributes of a namespace object are usually implemented as dictionaries, and class inheritance trees are (generally speaking) just dictionaries with links to other dictionaries.

Although we can store functions in dictionaries, too, using them to process implied instances is nowhere near as natural and structured as it is in classes.

In a sense, a module is like a single-instance class, without inheritance, which corresponds to an entire file of code.

Class attributes can also be created, though, by assigning attributes to the class anywhere a reference to the class object exists — even outside the class statement.

Again, though, they may be created by assignment anywhere a reference to the instance appears, even outside the class statement. Normally, all instance attributes are initialized in the __init__ constructor method; that way, later method calls can assume the attributes already exist.

Operator overloading is coded in a Python class with specially named methods; they all begin and end with double underscores to make them unique. These are not built-in or reserved names; Python just runs them automatically when an instance appears in the corresponding operation.

Despite its syntax details, Python’s class system really is largely just a matter of searching for an attribute in a tree of objects, along with a special first argument for functions.

Although other techniques (such as enclosing scope reference closures) can save details, too, instance attributes make this very explicit and easy to understand.

Cohesion: each function should have a single, unified purpose. When designed well, each of your functions should do one thing — something you can summarize in a simple declarative sentence. If that sentence is very broad (e.g., “this function implements my whole program”), or contains lots of conjunctions (e.g., “this function gives employee raises and submits a pizza order”), you might want to think about splitting it into separate and simpler functions.

Best practice in all Pythons recommends listing all your imports at the top of a module file; it’s not required, but makes them easier to spot.

PYTHONPATH and .pth files offer more permanent ways to modify the path — the first per user, and the second per installation.

Notice that compilation happens when a file is being imported. Because of this, you will not usually see a .pyc byte code file for the top-level file of your program, unless it is also imported elsewhere — only imported files leave behind .pyc files on your machine.

There is no way to extend an instantiable class and add a value component while preserving the equals contract, unless you’re willing to forgo the benefits of object-oriented abstraction.

Because shelves are Python objects containing Python objects, we can process them with normal Python syntax and development modes. Here, the interactive prompt effectively becomes a database client:

but slots — and other “virtual” attributes — won’t be reported as instance data.

To minimize the chances of name collisions like this, Python programmers often prefix methods not meant for external use with a single underscore: _gatherAttrs in our case.

A better and less commonly used solution would be to use two underscores at the front of the method name only: __gatherAttrs for us. Python automatically expands such names to include the enclosing class’s name, which makes them truly unique when looked up by the inheritance search. This is a feature usually called pseudoprivate class attributes, which we’ll expand on in Chapter 31 and deploy in an expanded version of this class there.

By coding functions and classes in module files, we’ve ensured that they naturally support reuse. And by coding our software as classes, we’ve ensured that it naturally supports extension.

We’ll use from to load in our script, just because it’s a bit less to type.

ZODB, for example, is similar to Python’s shelve but addresses many of its limitations, better supporting larger databases, concurrent updates, transaction processing, and automatic write-through on in-memory changes (shelves can cache objects and flush to disk at close time with their writeback option, but this has limitations: see other resources).

All the statements inside the class statement run when the class statement itself runs (not when the class is later called to make an instance).

In general, though, any type of name assignment at the top level of a class statement creates a same-named attribute of the resulting class object.

In Chapter 32, we’ll also meet Python static methods (akin to those in C++), which are just self-less functions that usually process class attributes.

Assignments to instance attributes create or change the names in the instance, rather than in the shared class.

Assignments to instance attributes create or change the names in the instance, rather than in the shared class. More generally, inheritance searches occur only on attribute references, not on assignment:

On a related note, you can also code multiple __init__ methods within the same class, but only the last definition will be used; see Chapter 31 for more details on multiple method definitions.

Every time you use an expression of the form object.attr where object is an instance or class object, Python searches the namespace tree from bottom to top, beginning with object, looking for the first attr it can find.

In fact, within Python, instance and class objects are mostly just dictionaries with links between them.

Python “best practice” rule of thumb is to use docstrings for functional documentation (what your objects do) and hash-mark comments for more micro-level documentation (how arcane bits of code work).

attribute access (a.k.a. qualification)

Inheritance-tree climbing happens only on attribute reference, not on attribute assignment.

any function that contains a yield statement is turned into a generator function.

Inheritance is best at coding extensions based on direct customization (like our Manager specialization of Person). Composition is well suited to scenarios where multiple objects are aggregated into a whole and directed by a controller layer class. Inheritance passes calls up to reuse, and composition passes down to delegate.

Like a def, a class statement is an object builder, and an implicit assignment — when run, it generates a class object and stores a reference to it in the name used in the header.

Normally we create instance attributes by assigning them in class __init__ constructor methods, but this isn’t the only option.

That is, a class is a local scope and has access to enclosing local scopes, but it does not serve as an enclosing local scope to further nested code.

Python’s super is like a box of chocolates — you never know what you’re going to get!

operator overloading — coding methods in a class that intercept and process built-in operations when run on the class’s instances.

Technically, __str__ is preferred by print and str, and __repr__ is used as a fallback for these roles and in all other contexts.

Design note: as we’ll learn in Chapter 30, the __repr__ method is often used to provide an as-code low-level display of an object when present, and __str__ is reserved for more user-friendly informational displays like ours here.

Sometimes classes provide both a __str__ for user-friendly displays and a __repr__ with extra details for developers to view.

Because printing runs __str__ and the interactive prompt echoes results with __repr__, this can provide both target audiences with an appropriate display.

The problem here is a very general one: anytime you copy code with cut and paste, you essentially double your maintenance effort in the future.

Think about it: because we copied the original version, if we ever have to change the way raises are given (and we probably will), we’ll have to change the code in two places, not one. Although this is a small and artificial example, it’s also representative of a universal issue — anytime you’re tempted to program by copying code this way, you probably want to look for a better approach.

composites. We’ll explore this pattern in more detail in Chapter 31, which is really more about design than about Python. As a quick example, though, we could use this composition idea to code our Manager extension by embedding a Person, instead of inheriting from it.

The more important point here is that this Manager alternative is representative of a general coding pattern usually known as delegation — a composite-based structure that manages a wrapped object and propagates method calls to it.

Still, object embedding, and design patterns based upon it, can be a very good fit when embedded objects require more limited interaction with the container than direct customization implies.

This method is a bit trickier to use, though, because assigning to any self attributes within __setattr__ calls __setattr__ again, potentially causing an infinite recursion loop (and a fairly quick stack overflow exception!).

If you wish to use this method, you can avoid loops by coding instance attribute assignments as assignments to attribute dictionary keys. That is, use self.__dict__['name'] = x, not self.name = x; because you’re not assigning to __dict__ itself, this avoids the loop:

Technically, instance creation first triggers the __new__ method, which creates and returns the new instance object, which is then passed into __init__ for initialization.

We’ll see one use case for __new__ when we study metaclasses in Chapter 40; though rare, it is sometimes also used to customize creation of instances of immutable types.

for calls iter, which calls __iter__

Python programmers are able to write large OOP frameworks and applications without private declarations — an interesting finding about access controls in general that is beyond the scope of our purposes here.

In general terms, the loop else simply provides explicit syntax for a common coding scenario — it is a coding structure that lets us catch the “other” way out of a loop, without setting and checking flags or conditions.

The name used as the assignment target in a for header line is usually a (possibly new) variable in the scope where the for statement is coded. There’s not much unique about this name; it can even be changed inside the loop’s body, but it will automatically be set to the next item in the sequence when control returns to the top of the loop again.

and indent all but the simplest of blocks.

Boolean and and or operators return a true or false object in Python, not the values True or False.

__next__ raises a built-in StopIteration exception at end-of-file

One of the first questions that bewildered beginners often ask is: how do I find information on all the built-in tools?

We met the list comprehension briefly in Chapter 4. Syntactically, its syntax is derived from a construct in set theory notation that applies an operation to each item in a set, but you don’t have to know set theory to use this tool.

Moreover, depending on your Python and code, list comprehensions might run much faster than manual for loop statements (often roughly twice as fast) because their iterations are performed at C language speed inside the interpreter, rather than with manual Python code.

As usual in programming, if something is difficult for you to understand, it’s probably not a good idea.

absolutes in performance benchmarks are as elusive as consensus in open source projects!

There are lots of people who aren't going to like this book, whether they are into morals or not. I figure there are three distinct groups of people who'll hate this thing. Hate group number one consists of most of the people who are mentioned in the book. Hate group number two consists of all the people who aren't mentioned in the book and are pissed at not being able to join hate group number one. Hate group number three doesn't give a damn about the other two hate groups and will just hate the book because somewhere I write that object-oriented programming was invented in Norway in 1967, when they know it was invented in Bergen, Norway, on a rainy afternoon in late 1966. I never have been able to please these folks, who are mainly programmers and engineers, but I take some consolation in knowing that there are only a couple hundred thousand of them. My guess is that most people won't hate this book, but if they do, I can take it. That's my job.