HackerObject-Oriented Programming is Bad
Brian WillYouTube ↗
Further reading 2
Does splitting code actually split its dependencies? →Start with a rule that sends an email. Separate deciding from doing, then inspect layers, objects and abstractions: which parts must still change together when the rule changes?This video helps answer · What makes an object useful?Can one record tell you both now and then? →Two reads disagree. First ask which moment each value describes, then who can change it. Keeping history and coordinating writes solve different problems.This video helps answer · Why don’t two locked objects make a safe transaction?
Caption notes
Will argues that coupling behavior to small data types can scatter changes across a program and explores plain data, procedures and larger module boundaries.
Original passages · 6
as soon as you have objects being shared encapsulation just flies out the windowthey exist simply as attacks to conform to this ideology about code modularizationare we actually decreasing the total complexity of our program or just displacing the complexitythe brilliant thing about pure functions is that they're the only truly self-contained unit of codethe problem is really not classes per seassociation between certain functions and certain data types