4 rules for happier objects

Having a good code structure helps your software to be maintainable and flexible well into the future. As software developers it’s our job to ensure the software is maintainable and refactorable.

The structure of code can make a big difference to how fragile and prone to bugs an application is. By embracing some simple guidelines and patterns we can write software that's more maintainable, flexible, less bug prone, and more fun to work with.

Transcript

1. 4 rules for happier objects (well guidelines)
2. Hugh Noble @HughNoble
3. Why should we care about our objects? • Having a good code structure helps your software to be maintainable and flexible well into the future. • As software developers it’s our job to ensure the software is maintainable and refactorable.
4. Objects should be immutable
5. What does this mean? • Once an immutable object is constructed it is not possible to change its state. • No setters. • No public properties. • No properties which are changed by methods. • Running one method won’t change the functionality of another.
6. Why? • Avoids temporal coupling. • Avoids side effects. • Easier to test. • Easier to mock out for other tests. • Follow a stricter contract.
15. Objects should always be in a valid state
16. What does this mean? • An object should either exist or not. • If it exists then it should be possible to perform all actions against it. • If an attempt is made to construct an object in an invalid state it should ‘fail fast’.
17. Why? • Avoids bugs caused by things being in an unexpected state • Reduces the number of possible states • Reduces the number of logic paths through the application • Requires much less error handling • Means you can trust the contract of a class
29. Objects should not extend other objects
30. What does this mean? • No object should inherit from another object. • Interfaces should be used to force contracts. • Common functionality should be injected by composition (constructor parameters) or be moved into different classes.
31. Why? • Easier to develop by contract • Much easier to write unit tests for • Aids with ‘failing fast’
38. Objects should not expose static methods
39. What does this mean? • No static methods in classes (except constructors). • Common functionality should be injected by composition (constructor parameters) rather than referenced as static.
40. Why? • Easier to develop by contract. • Allows with mocking for unit tests. • Helps with only letting objects be in valid state.
45. Conclusion • The structure of code can make a big difference to how fragile an application is. • By embracing some simple rules we can write software that is more maintainable, more flexible, less bug prone, and more fun to work with.