Back to basics

back to basics

twitter.com/paolopolcewww.webshell.it

mercoledì 23 novembre 11

http://www.webshell.it

http://www.webshell.it

back to basicsno matter how good your software development process is, you will still have to write some code

at some point.

twitter.com/paolopolce


Writing Software Is Engineering





• Software Projects Failure Reports

0

15

30

45

60

1995 2001

SuccessfulChallengedFailed




• Engineering components are real, while software is not.

• Interactions are more predictable in engineering.

• Software is required to change during development.

• There has always been the attempt to carry out software projects as if they were engineering products. But it never worked.


Bad news.Programming is not engineering.



Writing Software Is Science





• The scientific method is “a method of procedure that has characterized natural science since the 17th century, consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses”




• The scientific method is “a method of procedure that has characterized natural science since the 17th century, consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses”

debug driven design?


Writing Software Is Art





• In fact, as in film, music, sculpture, painting and all the other arts... software is...




• In fact, as in film, music, sculpture, painting and all the other arts... software is...

0

22,5

45

67,5

90

2011

MenWomen

equally distributed between men and women


Very disappointing.Programming is either not an art, or is not perceived as such.



There is no “Book”.Programming sits somewhere between engineering, science

and art. Do not expect to find “The Book” that makes everything clear about software.



Who writes software?I have met software architects, software analystis, even

software evangelists and then... resources!



Technical Skills Matter!



Do lots of deliberate practice(J. Jagger “97 things every programmer should Know”)


Athletes know the difference between training and performing.


TDD with MockObjects



Story #1 - News Aggregator

• as a user I want a NewsAggregator that shows me news of my interest so that I can read something, rather than having to listen to this very boring keynote.



Story #1 - News Aggregatordesign

• a NewsAggregator is something that

• receives user input in some way

• fetches the news somehow...

• displays the news somewhere

???

???

???twitter.com/paolopolce


Story #1 - News Aggregatordesign

• are we supposed to write a NewsAggregator without knowing how it will get the news and how it will show them to us !?

Yes, we are.



Story #1 - News Aggregatorsignature candidates...

public class NewsAggregator {

public ????? show(String searchQuery) {...}}




we tend to add useless getters only to be able to test our object via assertions on its internal state (i.e. the collection of news). But we are not supposed to access an object’s internals.Getters (and Setters) break the most important OOP principle: Encapsulation.List<News> is only a data container and is allowed to have a getter ;).But NewsAggregator is not a value object.


public List<News> show(String searchQuery) {...}}




Tip: replace the word “method” with “message”.

rather than saying “call the method Show() on the NewsAggregator”, we will say “send the message Show() to the object NewsAggregator”.


public void show(String searchQuery) {...}}

... but how do we test it, now ?!



Story #1 - News Aggregatortesting without accessing the state...

Following the Single Responsibility Principle, we don’t want our object to do all the work. Instead, we ask the NewsAggregator to collaborate with other two objects: a NewsFetcher and a Display.

Update the signature.


public void show(String searchQuery, INewsFetcher newsFetcher, IDisplay anOutputDisplay) {...}

}

Create two empty interfaces.

public interface INewsFetcher {}public interface IDisplay {}

note: I don’t generally prefix interfaces with the “I”, especially in Java.




So far, we haven’t written any working code. We have only established that our NewsAggregator should work with a NewsFetcher and a Display which we have not written yet. And we are not going to!

We’ll keep our focus on the NewsAggregator and “mock out” the two collaborators.

public class NewsAggregatorTest {...

public void setUp() throws Exception { m_context = new Mockery(); m_mockDisplay = m_context.mock(IDisplay.class); m_mockNewsFetcher = m_context.mock(INewsFetcher.class);

}}




@Test public void testNewsAggregator() { final List<News> fakeNews = new Vector<News>(); fakeNews.add(new News("a news")); fakeNews.add(new News("some other news"));

m_context.checking(new Expectations() { { oneOf(m_mockNewsFetcher).fetch("conferences"); will(returnValue(fakeNews)); exactly(2).of(m_mockDisplay).display(with(any(News.class))); } });

NewsAggregator newsAggregator = new NewsAggregator(); newsAggregator.show("conferences", m_mockNewsFetcher, m_mockDisplay);

}




public interface IDisplay { void display(News notizia);}

public interface INewsFetcher { List<News> fetch(String queryString);}

There is still no need to implement any of the collaborators. We only provide them with the signatures needed for the test.



Story #1 - News Aggregator


public void show(String searchQuery, INewsFetcher newsFetcher, IDisplay anOutputDisplay) {

List<News> someNews = newsFetcher.fetch(searchQuery); for (News aNews : someNews) { anOutputDisplay.display(aNews); } }}



Story #1 - News Aggregatorkeep the focus!

• The nice thing about the MockObjects technique is that it lets you focus on what you are testing.

• We don’t know how the NewsFetcher or the Display will be implemented. And we actually don’t care. What we do know is that once the collaborators will be available, our NewsAggregator will work.



Story #1 - News Aggregatorbest practices with mockobjects

• do not Mock value objects

• It’s very bad and useless.

• do not Mock classes.

• It’s a code smell you can easily avoid.

• avoid retro-fitting mocks into existing tests.

• only mock interfaces.



Story #1 - News Aggregatorrefactoring


public void show(String searchQuery, INewsFetcher newsFetcher, IDisplay anOutputDisplay) {...}

}

public class NewsAggregator { public NewsAggregator(INewsFetcher newsFetcher, IDisplay aDisplay) {...} public void show(String searchQuery) {...}}


move const dependencies to the constructor


Story #1 - News Aggregatortypical usage

NewsAggregator aggregator = new NewsAggregator(

new GoogleNewsAggregator(), new ConsoleDisplay());

aggregator.show("sport");


constructor injection


Object Composition



Story #1 - News Aggregatorgo patterns go!


GoogleNewsFetcher() YahooNewsFetcher() BingNewsFetcher()

CompositeNewsFetcher(G, Y, B)

NoDuplicatesDecoratorNewsFetcher(C)

new NewsAggregator( NoDupes, new ConsoleDisplay())








CompositeNewsFetcher

List<News> fetch(String query)

{gNews = m_googleFetcher.fetch(query);yNews = m_yahooFetcher.fetch(query);bNews = m_bingFetcher.fetch(query);

return g + y + b;}








NoDupesDecoratorNewsFetcher

List<News> fetch(String query)

{someNews = m_Fetcher.fetch(query);return removeDuplicates(someNews);}


Getters vs Messages


The Concert


Push your design, try to:

• remove getters

• remove singletons, or at least move them to the constructor, and use them as a service locator

• remove train wrecks

• refactor as you go.

• split responsibility as soon as your method reaches 5 or 10 lines of code.

• do not make your tests more complicated than the actual code, or you will have to test the tests.



Push your design, try to:

• don’t be skeptical!

• learn new stuff. You haven’t finished yet. No one has.

• make your code a pleasant place to live in (see Richard Gabriel’s “code habitability”)



Credits

• mock roles, not objects (Mackinnon/Freeman/Pryce/Walnes)

• http://www.jmock.org/oopsla2004.pdf

• 97 things every programmer should know (K. Henney et al.)

• http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

• why writing software is not like engineering (T. Parr)

• http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html



http://www.jmock.org/oopsla2004.pdf

http://www.jmock.org/oopsla2004.pdf

http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484

http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html

http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html

Back to basics

Technology

Transcript of Back to basics