Techniques for making reusable code
summary
Five practical rules: break systems into many small classes and decouple with small classes so swapping subsystems (asset repository, GUI, networking) keeps 60–90% of work when features change; stop using public GameObject/component inspector hooks and remove public GameObject references to avoid runtime nulls; prefer interfaces and compile-time checks to push errors to compile time; implement a message/event system with add/remove listeners, three-state messages, and late binding (used in a Unity C# MMO with asset bundles and SVN integration).
AI-written summary · about
chapters (27)
- 0:00Reusable code benefits
- 1:02Writing reusable code matters
- 2:04Four strategies for reusable code
- 3:07Compile vs runtime errors
- 4:10Smaller classes and interfaces
- 5:57Private members and loose coupling
- 7:20Decoupling for large projects
- 9:27Interfaces and their benefits
- 11:12Removing public references in Unity
- 13:15Avoiding hierarchy references
- 15:00Event model for async processes
- 17:28Instance events and encapsulation
- 19:53Three-state data handling
- 21:16Preparing for multiple events
- 23:00Safe event usage rules
- 26:09Singletons and listener registration
- 27:32Removing listeners on disable
- 28:58Event listeners example
- 31:44Event model abuse and alternatives
- 32:06Manager initialization order
- 33:27Decoupling vs iterative development
- 37:16Preventing GC with weak references
- 37:39Why not .NET events
- 38:41Alternatives to SendMessage
- 41:32Plain classes vs MonoBehaviours
- 44:16Networking solutions in Unity
- 45:18Summary and hiring
related talks
55mLet's Make Unity Great Again
47mDesign Patterns in Games
38mWriting Code That Lasts Forever
47mHow To Build Future Proofed Applications
18mWriting Quality Code
41mReusable Code, Reusable Data Structures
36mBuilding Strong Code Through Patterns
45m'Writing code that lasts'...or writing code you won't hate tomorrow