How to get started with Moldable Development
Moldable development in a nutshell
Moldable Development is a way to support decision-making by developing software in a way that makes it explainable . This is done by molding the tools and environment to your domain. In essence, you create custom tools for every problem you encounter. This makes the domain objects visible and explorable by means of custom views, actions, searches, advices, and other tools.
For some concrete examples, see Case studies of Moldable Development or Implementing a Ludo Game as a moldable development exercise.
Getting started with Moldable Development
Learn to program in Pharo and GT
To get started, you will first need to get used to programming in Pharo and GT. If you already have experience, you can skip this part. Otherwise you can start with A gentle introduction to Pharo Smalltalk.
Learn to program with live objects
One of the hardest things to learn about Moldable Development is to resist the temptation to start programming from the code editor. This is the traditional view that all mainstream IDEs offer.
The goal of Moldable Development is to create an explainable system consisting of explorable domain objects that allow you to quickly answer questions about the system using the custom tools that you build. The best way to do this is to always start from the live objects that you want to explore, and incrementally add the custom tools.
Once you have a live object, a good way to incrementally develop new behavior is to Contextual playground.
Learn to mold the tools
Moldable development entails molding the tools and the environment to your domain. This can be done in several ways.
The most visible custom tools are Inspector views. These allow you to customize what you see when you inspect an object of your domain simply by adding a method that uses the
Custom views are used in moldable development to highlight the most interesting and important aspects of a domain model. Often these are discovered as the application evolves. See Viewable entity to understand how repeated navigation can reveal the need for custom views.
Don't forget, you can always Secondary-click on the heading of an Inspector view to inspect its source code.
There are several thousand Inspector views defined in GT. (Inspect the result and go to the Metrics view.)
Custom actions are complementary to views. Like views, they are specified as methods, but with a
<gtAction> pragma. Instead of defining an Inspector view, they define the behavior of a button for the Inspector view of an object.
For example, if we inspect the image directory, we see four buttons to browse the class, inspect the object, open the directory in the OS, or to search. Each of these is a gtAction. Secondary click on each ofthem to see the source code. (The simplest one is the third, to “Open in OS”.)
As with views, the need for custom actions is usually revealed during development. See Custom action for details.
Note that there are also variants to mold other tools, such as Lepiter pages or Coders. The buttons at the top of this page are defined by
<lePageAction> pragmas. Secondary-click on them to inspect thier source code.
There are several hundred custom actions in the system.
Custom searches can be defined by methods with a
<gtSearch> pragma. Anywhere you see a Spotter (magnifying glass) search, there may be custom searches defined for various categories of searches.
For example, if you inspect this page, by clicking on the “(i)” button, you will see a search button that will show two categories of results, for snippets matching the input, and pages in the same database with matching titles.
If you secondary-click on the button, you will just see the definition of the search button. To see the custom searches themselves, click on the button, and then secondary-click on the categories (in grey), i.e., “Text & Code snippets” or “Pages.”
Explore the examples to get an idea of how they work.
Other ways to mold tools
There are numerous other ways to mold tools in GT. For example, custom advices (defined with the
<gtADvice> pragma) provide linting recommendations. Tools like the GtHome landing page and the debugger can be molded, with varying degrees of effort.
Opening up tools to be moldable is also an important part of moldable development. For a more general discussion of the principles behind moldable tools, see the paper Moldable Tools for Object-oriented Development.
Follow the best practice patterns
There are numerous best practices that can help you to apply moldable development effectively. Some of these are documented as Moldable Development patterns.