Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What does "toolkit design" mean and what are the basic steps to design a toolkit for a specific task/project?

It appears in a task description which says: "This task deals with the design of detailed specification of the various tools that are employed in order to implement [insert some development task here]"

So what I understand is that: it's required to design and provide the specifications of a toolkit which will be used for doing some specific tasks. But how is toolkit design done?

Searching Google hardly gives any meaningful result. They are mostly about "design toolkits" which is not what I'm looking for.

For example this guy has designed a software toolkit in some of his previous projects

share|improve this question
It is one of the layers in Layered Application Design (software). – rwong Jul 27 '12 at 13:53
up vote 2 down vote accepted

If you ask this question, you should not start designing toolkits ;-)

Putting jokes away, my view is the following (home made, no big names referred).

You have to build a software, which will solve a certain task. You have some specifications about different data objects, associated business logic, workflow, appearance, performance, etc. Requirements that your application have to meet in a certain environment (desktop or server, OS, frameworks, ...)

However, to achieve this goal, you probably will spend more time on "housekeeping" than implementing the actual algorithm, workflow, etc: you will store and read persistent data, process configuration information, command line parameters, scripts, manage the communication between the GUI and the business logic, handle errors. In more complex scenarios (like game development), you spend huge amount of time not on coding, but just building configurations (like design a level map, actors, etc), enable scripting and write scripts, ... Sometimes it is beneficial to create independent helper apps for doing such things. This latter stuff is what I would call "toolkit layer": not directly specified as a request, but you need them to do your job. And the better you design the toolkit layer, the more efforts it requires, but finally, when you have to solve your task, the tools make that pretty straightforward.

To put it simple: you can solve your tasks one by one independently - or extract the similarities, solve them once, and solving a "real" task means using the common layer in the specific environment. The problem: the common layer is

  • inherently more complex, as it should answer "any" question instead of "one",
  • hard to modify because many other codes depend on them,
  • and when it breaks, it may crash just about anything.

Nice theory, tough stuff.

If you don't have a vision of the toolkit behind your current task, I think you should not design it. Design your application in a nice, object oriented way instead: interfaces, abstract classes, shared helper components. The latter will be your "toolkit layer" for this application. If you have designed it well, this layer will help you when adding "one last new feature" or component to the app just before the deadline. If you can estimate the required time well in this situation, your toolkit is good.

... and if you live on this toolkit-drug for 20 years, you will not see the application, only the toolkit layer. This is why I create an automatic JSON serializer with a common persistence layer, and a data binding GUI toolkit for my ever first iOS application. I simply can't do in another way (and Objective C / Cocoa rocks)...

share|improve this answer
Thanks. Don't worry, I won't be the one designing it, I just need to understand what it is. – Gani Simsek Jul 31 '12 at 11:58
@GaniSimsek That was only a joke :-) The point is that a toolkit is an intermediate (partly domain specific) "language" between the implementation platform and the actual task. If you see it in this way, your abstract classes already form a kind of toolkit. Although you don't design a framework immediately, you can help in the process by analyzing particular tasks, separate top (leaf) and background/helper (sharable, node) processes. I think this is the best part of programming, not typing or debugging. Have fun! :-) – Lorand Kedves Jul 31 '12 at 12:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.