http://confreaks.com/videos/240-goruco2009-solid-object-oriented-design
Univerities like Enterprises but without the standards! Workes on long lived apps, not large data/users.
Your application will change. What will happen? That depends on it's design. Rigid app: everything is connected to everything else. One change changes all parts despite size. Fragile app: Like ragid, distant unpredicatble changes Immobile app: Hopelessly entangled so can't reuse anything. End up copying code - duplication. Viscous app: Easier to do the wrong thing then the right thing despite the architecture.
We didn't start out this way. In the beginning it was perfect. Like a flower, then it changed!
Unexpected dependencies are killing you. Design can save you.
Fowler: Time vs Features. Payoff from time. Everntually the lines cross. Design is like TDD, at first it takes time, so for a while you can get stuff done faster. If your app succeeds it will cost you money.
SOLID - From Robert C Martin. Terms for apps written by Bob. He didn't make it up, he took ideas floating around and gave them names.
Single Responsibility. Open/Closed. Liskov Sub. Interface Seg. Dependency Inversion.
SRP: Never be more reason for a class to change. OC: A module should be open for extension but closed for modification. (appears impossible!) LS: Subclasses should be substituable for their base classes (handy forumla) IS: Many client interfaces are better than one. DI: Depend upon abstractions, not concretions.
How can this help? Seems academic. This is a state when it is right. No guideance on how to get there. Common theme: managing deps in your app. Minimal entanglements, so you can change things. If an object is entangled, any changes cascade to other objects.
Freeman/Price: Loosely copulled (DI) high cohesive (SRP), easily composable, context independent (Dependencies).
IS: Only static typed languages care about this. As they use interfaces. Ruby doesn't have this problem. You depend on the signature of another method (duck typing). So Ruby solves this for you in the most extreme way, by removing interfaces.
Liskov: Subclassing. Does anyone use this? Hardly any. If calling code has is_kind_of checking you are not doing this. Most people don't do this.
Ground Rules: Only mock classes I own. Don't mock the object under test.
CSV Example: FTP code, parse code, update DB code.
Resistance is a Resource: You can push back, or listen to it and figure out what it's saying. Then fix it.
If testing seems hard - examine your design.
TDD will make your life a living hell if your design is bad. If it hurts, learn OOD.
Is it DRY? Does it have one responsibility? Does everything change at the same rate? Does it depend on things that change less often than it does?
Correct answer is YES. Other go change.
'and' is a code smell. OR is worse than AND.
Don't need to be smart to start with, just know the rules.
You can mock out when you refactor out responsbilities.
Don't create constructors that know class names, pass them in. Use the default for instance create.
FTP example : Separate config from non-changing code. Changes at a different rate.
Don't guess where you'll end up. Just follow the rules.
FTP example: found that we needed to test something we hadn't.
If statements are a code smell. It says the design of the object is not yet correct.
Refactor: Not because you know the abstraction, but because you want to find it.
People don't create beutiful code, they write crappy code, then refactor it.
Sandi likes using hashes instead of method params. Then extract them out.
Use metaprogramming for repetitive stuff.
Config, FtpDownload on the left, config on the right.
Low numbers are good. But some object do have to know.
Always depend on the things on your left. Not vice versa.
If you've injected your stuff, then it's easy to change the ordering.
Easy to use SFTP. But imagine you arne't told when! A feature of your app is changeable. Sandi puts the downloader type classname into the config.
TDD is good, but not enough. BDD same. DRY same. Design because you expect the app to succeed, and the future to come.
Does metaprogramming abuse Liskov? Nope, no is_kind_of Should we not care about IS? Nope, it's about static interfaces. Why DI? If you use something, put it in the constructure, easier to test and easier for future coders to reuse your code.