This set of code is derived from the work performed building the Direct2Learning Java Avionics training platform (now defunct).
It uses multiple inheritance, however base classes are pure virtual effectively to provide interfaces.
The code sample is missing the complicated ExecScheduler which is where the scheduling of modules is performed. Writing the ExecScheduler is reasonably complex - it needs to work with threads and provide timing. I've got a Java version of this which is at the end for illustration.
Everything is composed of something until you hit the fundamental elements of your domain. In a restaurant environment these would be what a chef would call ingredients, ie. stuff that comes from a food processing plant or a farm. However at the food processing plant these are the output rather than the input. I’ve tried to draw this below, it’s not complicated once you understand that it is a model of how things are.
So model this, using a table ProductBase
Ingredients, recipes, menus, etc. are all the same.
Frequently I see the same question in many forms; “How do I design a web application architecture”. The simple answer is that all application architectures are different, depending on the actual needs. Instinctively most programmers know what’s required, or at least we think that we do.
The true skill is to realise that we are often wrong and that any architecture design needs to be validated.
Pragmatic approach to application architecture
Pragmatism is one of those often misapplied terms that is often used interchangeable with “in my experience”.
Removal Of Control is a mechanism that will improve the usability, reliability and readability of code. I use commonly, it's similar in what I'm achieving but very different to IoC. The defining difference for me with ROC is:
Removal Of Control allows objects to be less tangled.
Developing from ground up a new IOS using WPF & C#
Previously for the event driven inter object communications in the Java MFD training I’d used a derived version of ARINC429. This worked well although it was clumsy in use.
Basic structure was to have a Message, within which there were multiple MessageDataItems.
The standard way of receiving a message is to implement the interface and then decode each specific message type, and then iterate through the contained messages.
Usually when designing a database there are a few fields in various tables that define things such as type, category, group. Normally these would be sufficiently important to justify their own entity within the database – so for example you’d have a category table.
Often when designing anything it is all to easy to forget the simple fact that when you add 1 to a number you will eventually be doing ADDQ.L #1, D2.
I follow, but not rigidly, the following rules of thumb
If you have a design with 2 classes you probably should be writing something procedural.
If you have a design with more than 30 classes it's probably time to revisit the design.
I've just realised that effectively I'm breaking my own rule of thumb No.4 "You don't need to write an application framework", and here I am writing one.
On a page where there are lots of views but all from the same entity there is an interesting challenge when an individual item is updated within a view. Normally this is catered for during a full postback simply because the entire page is recreated dynamically, so it is enough that the post is processed during the construct phase.
However this isn't true when we are using an ajax update to modify an item.
ZXAF is really the culmination of a lot of individual techniques that I've used in many different developments.
So, I decided to pull of these together into a project, release it as opensource, and continue developing it with a view to doing everything the right way. It is a development without a timescale or a budget, and its nice to be able to spend time on pure development.