Suggest chapters/topics for OOP Book

Question

I am working on a nuts-and-bolts^* book on object-oriented programming. The intent is to produce a short but practical tutorial and reference for the major concepts, pitfalls, practices, and promises of OOP while staying language-agnostic and steering clear of theoretical esoterica.

Each chapter will be devoted to a single concept or topic (including its limitations as well as its uses and advantages). Some of the obvious ones (so far) are:

• Introduction
• Data
• Code
• Object
• Message
• Method
• How an OO interpreter works
• Late/Dynamic Binding, Static Binding
• Reflection
• Information Hiding
• Classes
• Prototypes
• Encapsulation
• Polymorphism
• Inheritance
• Composition
• Composition vs Inheritance
• Classes vs Prototypes vs Templates vs Macros
• Interfaces
• Contracts
• Generics
• Events
• Exceptions, Callbacks, and Error Handling
• Object Lifecycle
• Design Patterns
• Refactoring
• Unit Testing
• Test-Driven Development
• Behavior-Driven Development
• Domain-Driven Design
• Aspect-Oriented Programming
• Glossary
• Appendices (optional catch-all for related topics, future directions, UML, tools, etc.)

(topics in italics are taken from suggestions below)

What other topics/concepts/chapters would you suggest, and why?

ADDENDUM: suggestions for intended common chapter structure (esp. quotes!) also welcome:

• Chapter title
• Chapter quote - like "What has it got in its pocketses?" -- Gollum, for Encapsulation.
• primer-style overview of concepts built from atoms of previous chapter's concepts
• Short illustrative story or analogy
• More formal definitions, as appropriate
• Brief history or background, as appropriate
• Exposition and illustration
• Obvious uses
• Possible pitfalls and traps
• Practical advice on topic
• Code Examples

I am planning to use a different language for the examples in each chapter, so the book would not be tied to a particular language - C#, C++, Java, SmallTalk, Ruby, Python, Perl, etc. Additional language suggestions welcome also.

ADDENDUM 2: It might be fun to have the 'homework problems' at the end of each chapter lead up to the implementation of a simple OOP scripting language, so the reader will truly understand how OOP works 'under the hood' [hence the title, Object Mechanics].

[^* by nuts-and-bolts I mean a practical how-to guide that primarily explains and demonstrates the mechanisms, with minimal theory and math]

UPDATE 2010-07-08: The book is now in progress, but no deadline for completion is set. Thanks again to all who helped me think through this complex and convoluted subject matter, and for all the great suggestions! The first chapter is available, adapted from this SO question answer

Answer 1

“Limitations.” I know that this might not seem useful but I think that any good discussion of a technique must show its limitations. Besides its obvious use, it also gives a much better understanding of the technique itself. Often, techniques are mistaken for something else because they seem all-encompassing.

Edit:

Examples for limitations vary depending on context. For example, in C++ (as a multiparadigm language) you should know when to make a clean cut and separate your object-oriented framework from a (potentially much simpler) STL-based solution. However, since you want to stay language-agnostic (basically a good thing), you could perhaps consider the problem of spurious dependencies. While OOP promotes docoupling and the reduction of interdependencies per se, it still often introduces a great deal of loose interface dependencies, making a potentially small system unwieldy (for example, try creating an IQueryable LINQ provider).

Another limitation of “pure” OOP suffers from the same problems as other pure techniques, i.e. the reluctance to compromise. Java's intentional omission of operator overloading comes to mind (notice that this is a purely syntactical problem, however).

Another point was raised by Stepanov (in a highly polemic manner), namely the mathematical limitation of the object oriented model. Don't be blinded by his aggressive tone, he has some true things to say. Applying OOP to a highly algorithmic framework is almost always a bad idea. Generic type systems à la Haskell (or even C++ concepts) potentially offer a more dynamic approach. In that context, it might also be worth mentioning that mixing generic type systems with OOP brings its own share of problems, e.g. covariance of generic subtypes.

That being said, these cases are surely exceptions to the rule.

Answer 2

I'd put something in there about ORMs and how they can allow for more OO work with databases.

Answer 3

An "Introduction" chapter would be great! =)

Answer 4

What about interfaces and inheritance.

Interfaces, because it is a whole new approach. Inheritance because it is an important and easily misused concept of OO.

Perhaps even OO metrics.

Answer 5

contracts, i almost forgot about contracts

like interfaces, but with more depth/detail

the difference between the two is: a class implements an interface, but satisfies a contract

the notion of "duck typing" is closer to contracts than interfaces, in some ways

Answer 6

Maybe a "Future of OOP" chapter, if that's not too much into "theoretical esoterica"?

For example, take a look at what Trygve Reenskaug (inventor of the MVC pattern) is working on!

Answer 7

Object modeling? UML?

If you have inheritance do you want to cover composition too?

Answer 8

• UML, at least class diagram
• design techniques and design principles (OCP, LSP, DIP, SRP ...)
• design smells

Do you plan to have a common structure to introduce all the concepts? Could you share it as well?

Answer 9

A glossary would help.

Answer 10

Version control

editor

complier

Integrated Development Environment

Answer 11

Warnings against class graphs that contain circular references.

Warnings against the temptation to make a 'Global' object to store all your 'global' variables.

The advantages of information hiding.

Answer 12

I suggest an explicit contrast with procedural programming.

Answer 13

behavior-driven development - if i'm going to talk about TDD and DDD, i can't leave out this other TLA ;-)

Answer 14

Object Property vs. (data) member.

Answer 15

How about a problem-oriented approach? Examples of using OO well, and examples of using it badly? I've seen entirely too many cases of making mountains out of molehills, all in the name of the wonderfulness of objects.

Just as structured programming was a remedy for piles of spaghetti code, OO was a remedy for raw-data manipulation see Alan Kay on OOP. Somebody (not he) convinced others that every brain-wave should be a class, so what we have now is piles of macaroni code.

Like every good idea, OO is best in moderation.

Answer 16

• Exceptions and error handling

Answer 17

Good programming means multi-paradigm programming. If you're only focusing on OOP, that's fine... But realize that the best, cleanest code results from the intelligent composition of multiple techinques, not just OOP concepts.

If you want to really contribute to the community, make sure you explain when functional programming is a better fit than OOP, when reflection/structural typing is a better fit than static objects, and why duck typing is almost always a better approach than static typing.

OOP is just one of the 5 paradigms, and it's not the best tool for every job.

http://computerlinguist.com/2008/09/04/use-scripting-languages-when-possible/

Answer 18

I didn'see anything about templates and genericity, which albeit not Object Oriented specific are supported in several OO languages. .

Answer 19

I'd like to see a table explaining how "each" language supports every concepts in such a book.

Answer 20

• CORBA, COM, IDispatch, RTTI, Reflection
• Dependency Injection, Late Binding
• Data Binding (with UI Control, XML, Database etc..) and impedance mismatch (dumb entity object vs information hiding)
• Interoperability (CORBA, Web Services, WS-*)

Edit:

• Attribute, Annotation, especially with its relationship to declarative security
• Concurrency, Java's synchronized method and notify() and wait()
• Multi-tier architecture

Answer 21

You should consider a chapter devoted to "Why inheritance is a bad idea". Also you might want to read Joshua Bloch's book, Effective Java.

Answer 22

Domain-specific languages (and/aka Model-Driven Development) are worth mentioning, if for no other reason than to deflate the hype they seem to be getting these days

note: every application constitutes a domain-specific language for the application domain

Answer 23

One of the biggest difficulties people have in picking up OOP is being able to model algorithms in terms of objects. You should consider devoting a chapter to the general issue of thinking about problems in terms of objects.

Humans have a tendency to classify physical objects according to shared characteristics. We often think of things in terms of hierarchical relationships, aggregates and collections. It may be useful to introduce these ideas by way of analogy in terms of concrete everyday examples.

A former coworker of mine had a job interview at Taligent back in its heyday. One of the interview questions was: "Is the universe object-oriented?" Her answer was to laugh and declare "That's the stupidest question I've ever heard!" (They hired her.)

I think the serious answer to that question would be "No, but the human mind is object-oriented."

Answer 24

object lifecycles are important to consider in system design:

• each object should be created, used, and destroyed in a manner that is consistent with the system states that it represents
• an object's lifecycle is considered "complete" if it is created, used, and destroyed while maintaining a consistent/valid state
• every object's lifecycle must be complete for the system to be "closed"

possible quote for this chapter:

I am not afraid of death, I just don't want to be there when it happens. -- Woody Allen

Answer 25

TDD, refactoring, unit-testing, et. all in a OOP book ??! AOP, BDD, DDD.. Design patterns.. these are all books in their own right. I'd suggesting keeping them out for fear of creating a book that tries to be everything for everyone and doesn't get read due to its size. (After all the effort you put into it.. nothing could be worse than that)

My Suggestion:

1. Keep it thin. Keep it light. Maybe a few levels over the Head First style.
2. Get the OOP ideas of Encapsulation, Polymorphism, Inheritance-Composition and do a stand-up job with them. This would be the make or break point.. anything above this would be a bonus. This could be 60-70% of your book.
3. Object Thinking / Modelling.. how not to carry your procedural baggage into an OO language. Something like the essence of David West's book. Highlight benefits of Low Coupling and High Cohesion. The object-as-a-person metaphor is something you must include.. even if you have to cut a piece of the pie for Mr.West
4. Basic object terminology that you might hear in the wild: messages, parameter passing, protocol-interfaces, events, etc.etc. a page or two each with illustrated examples
5. Minimal UML needed to get by to communicate with fellow designers. APPnP does a great job at this.
6. Dragons of OO: Anti-patterns basically.. like overengineering, tangled inheritance hierarchies, composition over inheritance in desc order of prevalence in the real world.
7. Appendix: Limitations as Conrad has pointed out.. but this won't be more than a couple of pages.

So much for now :)

Answer 26

Perhaps you could write a section to compare OOP to other styles of programming

• Procedural
• Logical
• Functional
• Aspect Oriented

and point out the pros and cons of each. I'd be interested in reading that.

Answer 27

one of the interesting issues in refactoring is the "telltale signs" that a class is missing. In general, switch statements and if statements may indicate a missing class.

Sometimes the refactoring replaces the if/switch via polymorphism (each switch case becomes a method in a subclass, assuming the switch condition is a type discrinimator), while sometimes the refactoring replaces the if/switch via encapsulation. The latter case is a bit more subtle to spot, but in general there will be some association manifested in the if/switch statements that binds values together that do not belong to the same class but probably should. See this question's answer for a simple example.

a full discussion of refactoring is beyond the intended scope of the book (Fowler's got that covered pretty well already) but some of the semantics are worth discussing so that the reader understands the principles behind the mechanisms.

Answer 28

You can add Common Lisp CLOS to the languages, it is a very impressive implementation of OOP (read The Art of the Metaobject Protocol if you haven't, it is an enlightening book on OOP, defining a metaobject protocol for CLOS).

Answer 29

You can also add Lua and Javascript to the languages, their prototype-oriented OOP is minimal but easily extensible. See Joose for a nice example of Javascript extension.

[Edit to answer comment]

Lua provides facilities & syntactic sugar to support an object-oriented programming style. Chapter 16 of Programming in Lua (PiL) describes simple OOP programming styles in Lua.

For more advanced features, like a super() function, you can write your own OOP module in Lua (I'm trying to write one here) or use one of these.

Answer 30

While there are many comments about UML, etc. I think you may want to make sure you have something on documentation. I have seen way too much code where the design is such that it is next to impossible to figure out what to modify. So people write hacks to make things work (which usually make things worse.) I don't think this needs to be a chapter, but you may want to consider suggestions (when applicable) on what approaches (UML, whatever) the user may want to consider so that those who come after will be able to edit the code as was intended. And this is by no means limited to UML. Anyone who is new to a framework has had to learn the "right" way to implement something.

It certainly appears that you have more than enough material for a substantial book. You may want to consider 2 (or more) versions. A short version as a quick reference, but no real detail. A second, with much more detail (probably along the lines of what you currently have in mind). And maybe a third that uses a wiki/user contribution approach that allows people to add content in addition to what is in the book (examples, additional concepts, topics that were just too much to add to the book, etc.)

Anyway, good luck with the book. No need to comment, use or ignor as you wish.