Frequently Asked Questions
How does StrataCode integrate with other software programs?
StrataCode leverages standard Java patterns like Java Beans so you can use Java classes without modification. You can add annotations for your classes to customize how code is generated for those classes when they are used with other StrataCode features. For example, if your class implements some type of parent/child relationship, you can add a simple code template for that class which customizes the code generated for the object operator.
StrataCode's core infrastructure is based on a very flexible parser/formatter which makes it easy to read and incrementally update new code formats. You can convert them to Java or JS or do processing on them. Whereas most frameworks support import and export, StrataCode's model makes it easier to support synchronization - where changes move back and forth between systems more automatically. You can use layers of code, files, and data to buffer those changes to implement workflow when this synchronization requires an explicit review/approval stage for quality control. You can use layers to model the overlap between two systems, and to incrementally customize the differences.
How does StrataCode speed development times?
There are several ways StrataCode speeds development. First of all, it offers high level, declarative coding patterns like today's best platforms. Developers can do more with less code. By making code more declarative, it's easier for others to make changes. Jeff's experience helped him choose the patterns he has observed make for the most solid, efficient applications. StrataCode does not include new patterns which make code harder to read.
Secondly, StrataCode eliminates the need to replicate your domain model's logic throughout the application. For each property in your domain model, most frameworks and platforms require you to replicate the logic behind that property several times, once for each layer in your system. With StrataCode, you specify the properties and domain logic that goes with just once. If you need more control, you annotate those properties with layers and get precise control over how the framework treats those properties. When there's only one copy of your domain model, you can change it rapidly as your business requirements change.
Thirdly, StrataCode offers live programming with code-patching in a client/server environment. This lets you build applications incrementally, and make changes without length recompile and restart sequences.
Why are layers better than just plain inheritance?
Of course lots of times object inheritance is what you want, but other times you really want code to be a customization to an existing type - a mixin or plugin etc.
When you use inheritance, e.g. "A extends B" you always create a new type name, in this case "A". Because inheritance is our only way to refine a component, creating a new type is design-wise expensive. It's generally a bad idea to create lots of classes, one per feature as it can make code more verbose, harder to read and manage. A layer however can group multiple related and interdependent refinements with a single name. The layer may represent a feature, or an aspect of behavior like user-interface, persistence. It helps you break up large files and navigate code. It's easy to merge them for viewing and debugging.
The main pattern for refinements, and plugins in Java today is to use dependency injection: create a new class which extends the original class, then point the component definition to the new class. Compared to a layer, that's more work and requires up front planning which you have to get right for compatibility.
And you've created a whole new name space - the component name-space which adds a constant multiplier to your code complexity. You're now doing runtime mapping of those references which adds a multiplier to your testing burden and startup overhead. And you need new tools to manage those references.
Layers provide a more powerful and flexible, in-language mechanism for customization. One name-space, statically-typed references - find-usages, refactoring all work reliably just as in Java. You can change things and customize things without refactoring and without breaking compatibility. They work at compile time and/or at runtime depending on how you configure them. There's one integrated language model for seamless tooling - where the program can edit the program in a nice contained sandbox.
And when you don't want to use layers to modify types, they act just like modules. You can only use layers to make your build system more powerful.
A few languages let you modify types either using dynamic types or extension points. When you let any piece of code modify any other piece of code, it makes tooling and tracing the origin of the code more difficult. Layers give you flexibility with the right structure to make it maintainable as the code base grows large.
What would make a good pilot project?
What about IOS?
We are tracking efforts to bridge Java to IOS. There are three which are becoming relatively mature. Another option is to convert Java/StrataCode to Swift.
What about .NET?
It's very feasible to convert SC (and at the same time Java) to .NET. It could be useful in a heterogenous Java/.NET system given that layers can tease apart platform dependencies and synchronize overlapping parts.