OOP: a single class

An approach that keeps a thing's data and the operations on it in one place. A book's title and its borrow() method live together, rather than the data in one structure and the code elsewhere.

A class is the template, saying what every one of this kind will have and can do; it holds no values itself. An object is one actual thing made from that class, with its own values.

Inheritance is reusing what a more general class already has — Ebook takes Book's title and author. Polymorphism is the same method call answered appropriately by each kind. Inheritance often makes polymorphism possible, but they are different ideas.

Advantages: it models real things with data and behaviour, and inheritance gives reuse with no copied code. Disadvantages: the class structure must be designed before coding, and it is more code than a small task needs.

For a short script with no real entities to model — reading a file and printing a total gains nothing from classes while still paying the design and code overhead.

Underline the nouns as candidates for classes and attributes, and the verbs as candidates for methods. It is crude but gets a first draft right surprisingly often.

The name at the top, the attributes in the middle with their types, and the methods at the bottom with their return types — always in that order.

A minus sign means private, reachable only inside the class. A plus sign means public. An underlined entry is static, belonging to the class itself rather than to each object.

In the class that holds the data it uses. borrow() belongs on Book because Book holds onLoan; putting it elsewhere would force that attribute to be made public, losing encapsulation.

When the relationship is really 'has a' rather than 'is a'. A Library has Books but is not a Book, so it should hold a collection rather than inherit.

A non-static (instance) variable has one copy per object, holding what makes that object different. A static (class) variable has exactly one copy belonging to the class itself, shared by every object.

Because it is a fact about the class, not about any one object. As an instance variable, every object would hold its own count of 1 rather than a shared running total.

An instance method uses the object's own data and cannot be called without an object. A static method belongs to the class, uses no object's data, and can be called as Book.count() with no object at all.

It can be called with no object in existence, so there is nothing for self to refer to — no way to know which object's data was meant.

Would every object have the same value, always? Yes means static; no means it must be an instance variable. In doubt, choose instance — sharing one value is a decision, not a default.

Defining writes the template once, saying what every one will have and can do. Instantiating creates an actual object from that template, with its own values, as often as needed.

It runs automatically when an object is created and gives every attribute a value, so no object ever exists in an unfinished state. It can also refuse invalid values before the object exists.

The object the method was called on. self.title is this particular book's title, which is what lets one method definition serve every object of the class.

Some have a single correct starting value. A new book is never on loan, so onLoan is set to False inside the constructor rather than asked for — which removes a chance to get it wrong.

The object exists with a missing value, and the failure appears much later, somewhere that has nothing to do with the cause — which makes it hard to trace.

Keeping an object's data private and providing public methods as the only way to reach it, so every change goes through code that can check it first rather than any part of the program writing whatever it likes.

Encapsulation is the mechanism — private attributes, public methods. Information hiding is the principle behind it: the outside should know what a class does, not how, so the inside can be rewritten without breaking callers.

A getter returns a private value; a setter changes one after checking it. Providing a getter but no setter makes a value readable from outside but not changeable.

The data is then effectively public with extra typing. The value of encapsulation lies in the checking that happens on the way in, not in the wrapping itself.

The fault must be inside that class, since nothing outside could have written it. With a public attribute, any line of the whole program could be responsible — the same argument as preferring local variables to global ones.