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 http://logonpro.com/resume.doc

  • It is one of the layers in Layered Application Design (software). – rwong Jul 27 '12 at 13:53

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)...

| 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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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