You are completely right, I meant

• Open 1...n workbooks
• iterate through 1...N worksheets * set parameters * set formats

But wait. I wasn't talking about really implementing it. What I am interested in is the overall architecture. You talked about a replacement of design patterns - an alternative well known best practices that also accomplishes transparent, maintainable, extensible and understandable code. You really don't need to create a working system - I already implemented it ;-)

Let's discuss on architectural level, and only care about the how without the actual doing.

These are good questions!

Can I do the job without relying on OLE because the source files are in text XML? Not having to rely on an OLE server and processing XML content is way faster and controllable than using an OLE server.

Of course this should be a scalable solution, but we should use OLE. This is for one good reason: You can build up Excel workbooks with XML, but you cannot calculate, change pivot table field values for filtering, and the only application that is capable of rendering Excel->Pdf pretty well is the Excel application itself. So you need to work with "real" Excel application.

Are we talking about processing farms? Or are we talking about a single application that does these steps?

We are talking about having the possibility of running multiple Excel instances side by side on one machine while it should be possible to have multiple machines running.

Is it a batch script or is if a C# application?

It should be a c# application. There are some PIAs for Excel that are pretty good to be used

Does it run on servers without UI or just user PC's where the user can click on close when it messes up?

Let's assume we don't take care about any user interfaces and this is just an engine processing workbooks.

Where do I get these source files from and where do the generated pdf files have to end up to?

Let's assume it is not important. You may choose whatever is appropriate.

I am really interested in the overall architecture that you are going to choose.

Anyway, enjoy the weekend :-)

you are really passionated, I like that :-).

However when academics try to quantity these design patterns and shoehorn them into some abstract way to designing software you basically killed the reason why this pattern was design in the first place: "To solve a specific problem and make your code readable"

Let's say the measureability is a crucial and problematic point in software development. Classifying a developer is not easy. I understand why it is done, that doesn't necessarily mean it is done in a sensible way. This is pretty comparable to IQ tests.

Now why do people think that design patterns are miracle things? Because they are so used to bad design that no one knows anymore what a well design program look like. Developers are so used to see design patterns that no no notices that these are crippled programs.

I don't know if I would pass over the responsibility of misuse of design patterns to managers. I don't consider design patterns to be magic.

This one is hard to explain if you never grew up with code that is elegant in design. Everybody has forgotten how to program. But I challenge you to kick out design patterns and unit tests, kick out agile development. And develop your program from scratch. Force your creativity as a develop to find new ways to solve a problem. Develop in such a way that your code becomes part of intellisense.

Actually I did all of that. When I started with programming it has been basic, then 8-bit assembler. You cannot be more close. The elegancy and beauty of perfect assembler code is pretty unmatched. Then moved on to VBA, VB6, .net, Java. I was searching for a long time after things that make programming more transparent, better understandable, and, this is the most important piece: Discussable on the same page. When you dont use design patterns due to you don't like how they are promoted, or you reinvent the wheel, you have one big problem: It is hard to get the same wording with other developers. That is main attraction of design patterns. A lot of developers will anyway use them, but they don't have the right name for it. That makes it easy.

There are reasons to kick out all the strategies in development, but I even do not do it "dirty" when it comes to prototypes. I am just faster using sensible strategies. BTW when I talk about design patterns I don't mean I blindly apply them.

Rules have been made for beginners, experts break the rules.

Let's give it a try, please think about how you would solve the following problem (architectural): Let's assume you have to do Excel automation. You need to take the following steps:

• Open Excel Application
• Load Excel Addins
• Open 1...n workbooks
• iterate through 1...N worksheets
• set parameters
• set formats
• export the worksheets as pdf
• close the workbooks
• close the Excel Application

Be aware about the following constraints:

• even in case of a misbehavior, it is not allowed to leave the Excel Application opened or a workbook being opened. System must be clean afterwards
• Excel is an OLE Server. That means it is able to reject calls from you. If it does so, you need to be able to repeat your call to Excel.

Let me know your thoughts!

All these criterias sound absolutely sensible. Your last sentence raises a question mark for me. Let me ask you two questions:

1. If you don't use well proved best practices in your program, how do you make it understandable for people that are not you?
2. I don't get the point why design patterns are against testability. Could you shed some light for me?