Mixed feelings about the talk. Encapsulation and breaking encapsulation can be key. I started in networking and had the clean OSI/ISO stack pictures in my mind.

Mixed feelings about the talk. Encapsulation and breaking encapsulation can be key. I started in networking and had the clean OSI/ISO stack pictures in my mind. Then looking at the management plane of a network stack TCP protocol, the transport layer details and a few other telco network stacks I started understanding the really interesting bits happen at the edges where the layers meet. Some applications cut across the layers. He got some good points in his analysis with respect to fine granular OO design. The reasoning around the need to break encapsulation was illustrative. If objects are too small they will have a lot of surface area and their interconnection is hard to reason about. In OO programs control flow is not easily graspable from reading code. If the object graph is a tangled mess then the team will have an exciting time. Pulling out the program flow into a large procedural piece of code can look attractive. In my experience such pieces of code incidentally are found in ..Service ..Manager classes the speaker is not so fond of. At times this may be a clearer and more effective approach than managing the object graph and distributing logic to messages. But going to procedures of several hundred lines is imho going to far. When I think about it then software needs to be testable. If the objects are too trivial and a lot of logic is in their interconnection graph then the risk increases that the important bits are not tested - after all we got close to 100% coverage. But it is still possible to build the graph and test it in a meaningful way. Being OO I can instrument it too with test frameworks. That seems less the case with a longer piece of linear code.