Is it good practice to compose an application through multiple .exe? [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

in a book - I think it was Eric S. Raymonds "the art of unix programming" - I read sth. like that applications should be built by putting multiple small tools together.

So, I开发者_StackOverflow would like to know if it's a good idea to develop a windows application, for example, by creating one small .exe for every task?

For example: You have a Document Managing System:

This could be put together like:

• an .exe for searching and displaying documents (GUI)
• an .exe for indexing document (put documents into a database)
• an .exe for deleting documents
• etc.

Do you think this would be a good idea or should it be put into one big .exe with multiple DLLs (this would be the way I saw most applications built)?

What would be the pros and cons?

---

There are indeed plenty of pros and cons when we consider the granularity of components, services, deployable units etc.

In the traditional command-line unix world we manipulated data in the form of text files, each line being a record and maybe with fields delimited by commas or tabs or spaces. Then lots of little utiliies could be developed and we had huge fun with "cut", "join", "tr", "grep", "sed", "head" etc. Personally, I still make sure that I have these tools in my Windows environments.

Why does this work so well? A fundamental file format agreemnt: lines and columns. We can add new utilities and know they will integrate. Never a need to change an old utility because we added a new one. Also no GUI, we expect to work at the command line. We just launch pipelines of tasks to get the job done.

Now what do you do when things get more complicated? When you want to offer GUIs. Simple approach: bit the bullet release an single App. New function, new app version. That may not be so bad, you change some aspect of the UI, need to change some file formats or APIs, so other pieces change too. Much easier to release a single, coherent, (maybe even) tested whole.

However as the scope of the UIs increase it's rather disruptive to release everything. Hence the emergence of component models such as OSGi, which is exploited by Eclipse, so that a single UI can be assembled from many separately developed and evolving pieces.

---

In my opinion:

Yes and no. A few factors go into deciding whether or not a disparate .exe should be made. In the grand scheme of things, you have to decide whether the task that is being performed warrants its own file. A large factor is deciding this is whether or not it serves an independent purpose from your central application. Following this, you also have to decide whether your application is localized into one package or is more of a series of utilities that can be utilized independently.

From a user-perspective, people don't like having multiple programs open at once. Going back to your example, here's how I would do it. I would have one .exe as the main program for:

* an .exe for searching and displaying documents (GUI)
* an .exe for deleting documents
* etc.

And then have a separate .exe that acts as a background indexer, performing the second functionality that you listed.

Really, it should be something evaluated on a case-by-case basis, keeping in mind intelligent UI design from multiple perspectives.

Edit: Also, you may find yourself in situations where alternative means of separation are more suitable (i.e. tabs, dialog boxes, etc.)