pieces in place； and when called will seem like it functions。 The echo part es in when the end piece of functionality is called and it returns the data that was sent to it。 In essence； the end piece is acting like an echo。 The cleverness behind the echo is that it requires no implementa tion； yet it demonstrates the plete flow of data and whether that data flow is workable。 The echo program is not a final program。 The echo program is a temporary solution for an intermediate goal。 When building an application with intermediate goals； you are using an iterative development technique。 The iterations are not visible to your other team members and are pletely private。 However； the iterations will keep you focused on solving a problem； rather than trying to implement a large piece of code that you will not be able to fully test for a while。 Test…driven development； for the most part； is a bottom…up development approach。 You develop a core piece of functionality； test it； and then write code that uses the tested piece of …………………………………………………………Page 275…………………………………………………………… CH A PT E R 1 0 ■ L E A R N I N G A B O U T P E R S IS T E N CE 253 functionality。 But sometimes you need to develop in a top…down fashion。 I typically develop code top…down when I am trying to nail down an overall architecture。 The problem with devel oping top…down is that you don’t yet have the bottom code。 In other words； you are writing code with no working code。 So that your code does have some meaning； you develop an echo。 The echo solves the problem of working code and allows you to focus on getting the individual pieces to fit together。 Once the pieces are working； and the echo was successful； you can start filling in the implementations。 Some developers call the echo a mock implementation。 Here； I’ll explain developing the sample application by assembling individual pieces in a top…down manner； focusing on getting a single echo implemented。 Then once the overall flow is plete； the individual pieces will be implemented pletely。 Figure 10…2 illustrates a plete architecture for the lottery…prediction program； including the pipeline for the TextProcessor console application。 Figure 10…2。 Architecture of a reader/writer application using a general assembly Reading and Writing to a Stream For developing the lottery…prediction application； we’ll use a piece of bootstrap code to initiate the reading and writing library； which then calls the specific implementation。 Bootstrap code is code that does not actually perform the processing； but is responsible for setting up and initi ating another piece of source code that will do the processing。 This is the same sort of architecture as we set up in Chapter 8’s example； for the applica tion to control the lights of a building。 In that case； the controller was a generic piece of software that called an interface； but did not know about the individual implementations。 The focus there was on developing the room implementations； and the lighting controller was left as a nebulous to…do task。 Here； we’ll go through the creation of a plete working application； including the controller and implementation。 Note this chapter is light on testing routines； both for brevity and because one of the exercises at the end of the chapter is for you to e up with a testing plan。 We want to be able to process the following mand line。 type lotto。txt ｜ TextProcessor。exe …………………………………………………………Page 276…………………………………………………………… 254 CH AP T E R 1 0 ■ L E A R N I N G A B OU T P E R S IS TE N CE If TextProcessor。exe cannot read the data from the pipe； an exception will be thrown at the console level； indicating that the piped data was not read。 ■Note For the application to work； the lotto。txt and TextProcessor。exe files must be in the same directory。 By default； TextProcessor。exe is in the ＇Visual Studio project＇bindebug directory。 Copy TextProcessor。exe into the lotto。txt directory； or vice versa； or you could even copy them both into another directory。 In the architecture of TextProcessor； the bootstrap code is in the ReaderWriter project。 The TextProcessor console application must call the bootstrap code and instantiate a local type that has implemented the IProcessor interface。 The Main（） method of TextProcessor is implemented as follows （this is the best time to add a reference to the ReaderWriter project by right…clicking TextProcessor and choosing Add Reference Projects ReaderWriter）： Imports ReaderWriter Public Module Module1 Sub Main（ByVal args As String（）） Bootstrap。Start（args； New LottoTicketProcessor（）） End Sub End Module TextProcessor。Main（） passes all of the given arguments （contained in the args array） to the actual processing routine （Bootstrap。Start（））。 The LottoTicketProcessor class imple ments the IProcessor interface and will serve for the temporary purpose of echoing data。 The IProcessor interface is defined in the ReaderWriter project as follows： Public Interface IProcessor Function Process（ByVal input As String） As String End Interface The IProcessor interface has a single method Process（）； which accepts a string to be processed； and the return value is the processed string。 The implementation of LottoLibrary。LottoTicketProcessor is as follows （remember to add a referenc