Zircon is designed around some very simple, yet powerful design principles.
First we try to shave with Occam’s Razor. If there are multiple solutions for the same problem we try to pick the one which is simpler. Of course there are caveats for this: we can only make this decision if two solutions can solve the problem in a way which does not take away functionality.
We try to make all our classes SOLID. This is one of the most important design principles which are the backbone of the Zircon codebase.
We try to keep the architecture of Zircon Clean.
This is especially important in a text GUI library where users can mix and mach
Fonts, GUI frameworks, and such.
This design principle let us abstract away the details of Swing, Java2D, Font handling and by using clean architecture
we were able to test most of our classes both in isolation (unit tests) and in integration.
By dividing the codebase to an
api and an
internal package we can supply you with a robust API which you can
rely on. You can expect all classes / methods in this package to not change nor in signature or expected behavior.
Check this talk by Rich Hickey if you want to learn more.
Immutability and Functional Programming
Most components in Zircon which can be immutable are immutable. We’ll work on this in the future. There are a lot of advantages of immutability, and you can read about it in a lot of places if you are interested. We use Functional Programming where applicable and where it makes sense. We think that in most places it will lead to more concise and also more simple code.