Those of us whose work is to write software are incredibly lucky. Building software is a guiltless pleasure because we get to use our creative energy to get things done. We produce things that matter.
Applications that are easy to change are a pleasure to write and a joy to extend. They’re flexible and adaptable. Applications that resist change are just the opposite; every change is expensive and each makes the next cost more.
Getting the right message to the correct target object requires that the sender of the message know things about the receiver. This knowledge creates dependencies between the two and these dependencies stand in the way of change.
Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change.
Your class can be no longer than 100 LOC Your methods can be no longer than 5 LOC You can pass no more than 4 parameters Controller actions can only instantiate one object You can only pass one instance variable to a view
T.R.U.E. Code Transparent The consequences of change should be obvious in the code that is changing and in distant code relies upon it Reasonable The cost of any change should be proportional to the benefits the change achieves Usable Existing code should be usable in new and unexpected contexts Exemplary The code itself should encourage those who change it to perpetuate these qualities
Your class can be no longer than 100 LOC Your methods can be no longer than 5 LOC You can pass no more than 4 parameters Controller actions can only instantiate one object You can only pass one instance variable to a view
Design • The arrangement of the code • Defer decisions and reduce the cost of change • What is the future cost of doing nothing today? • Cost per feature over time interval that matters
Dependency when an object • Knows the name of another class • Knows the name of a message it intends to send to someone other than self • Knows the arguments a message requires • Knows the order of those arguments
Classes control what’s in your source code repository; messages reflect the living, animated application. Design, therefore, must be concerned with the messages that pass between objects. It deals not only with what objects know (their responsibilities) and who they know (their dependencies), but how they talk to one another.
Public Interfaces • Reveal its primary responsibility • Are expected to be invoked by others • Will not change on a whim • Are safe for others to depend on • Are thoroughly documented in the tests
Thanks! Sandi will be speaking at La Conf in Paris 9-10 May http://2013.la-conf.org 3 course meals, wine tastings, really great speakers 20% Discount Code: RubyIreland Thanks Intercom! Intercom are hiring - We’re not allowed to leave until someone agrees to work for them!
chrismcg
hcrane
chatii
guikingone
smiyawaki0820
alli83
fishofprey
77web
kubotak
speed1313
mpyw
yuya4
robhawkes
notwaldorf
brianwarren
ddemaree
bkeepers
jakevdp
searls
pedronauck
bcantrill
bryan
morganepeng