Hi,Scheme:I have N vanilla IR swaps configured in my Bloomberg Swap Manager (SWPM, transaction pricing/risk platform in Bloomberg). Each configured swap transaction is identified with unique Bloomberg ticker. By using this unique ticker, it is then possible to request different valuation fields for a swap transaction by using Bloomberg API.The purpose of the program is to read in all Bloomberg tickers from [source], send data request for Bloomberg API and finally, write result data for all requested transactions into [target].In essence, the program1. is first creating portfolio object, consisting of N different transactions (N vanilla IR swaps).2. is reading transaction data [bloomberg tickers] for each transaction from a selected source (file, console, database, excel, etc).3. is then requesting M valuation fields from Bloomberg API for each N transactions in portfolio.4. is finally writing out all M valuation fields for N transactions into a selected target (file, console, database, excel, etc).In order to decide how to create possible design as flexible as it could be, I have been thinking to :- use Builder pattern for creating transactions from different sources [bloomberg tickers for each swap transaction].- use Visitor pattern for writing the resulting data into different targets.What kind of design you would be using for this kind of scheme?Any comments or suggestions are mostly welcomed. Thanks.BR, Mike Juniperhill

Thanks a lot for your pointers. Some of those I have not been even thinking about ..-Mike

QuoteIn order to decide how to create possible design as flexible as it could be, I have been thinking to :- use Builder pattern for creating transactions from different sources [bloomberg tickers for each swap transaction].- use Visitor pattern for writing the resulting data into different targets.Hi Mike,What do mean by "as flexible as it could be"? i.e. is your solutionA. Bloomberg-independent (also Reuters)B. Operating system independent C. Other data-related independence (e.g. ADO.NET)?Going for an OOP approach will lead to Visitor, Builder, Bridge and others, possibly. An interface approach will lead to a design like the Monte Carlo C# design doc. I find the latter more flexible in some cases. You decompose the system into components with water-tight interfaces.QuoteConclusionWe have tried to demonstrate by these examples thatit is almost always incorrect to begin the decompositionof a system into modules on the basis of a flowchart.We propose instead that one begins with a list ofdifficult design decisions or design decisions which arelikely to change. Each module is then designed to hidesuch a decision from the others. Since, in most cases,design decisions transcend time of execution, moduleswill not correspond to steps in the processing. Toachieve an efficient implementation we must abandonthe assumption that a module is one or more subroutines,and instead allow subroutines and programsto be assembled collections of code from variousmodules.Received August 1971; David Parnas. I created something similar a while back for CAD See Figure 1 here