@page Other @subpage Architecture @page Architecture Achitecture
| Software Layers |
|
|
|
|
|
| Application Layer |
|
|
AppLayer * |
|
|
| ^ |
App Plugins |
|
|
|
|
| ModuleA |
ModuleB |
ModuleC |
|
ModuleD |
Plugins |
| Core |
|
|
Foundation |
|
|
| Utilities |
|
|
|
|
|
| C++ Runtime Library |
|
|
OS |
|
|
| Hardware |
|
|
|
|
|
* Note, limitation of markdown to create a non-rectangular table cell
Basic Principles
- DRY - Don't Repeat Yourself
- Orthogonality
- Software Layering
- Referential Transparency
- Test driven development
- Data oriented design
DRY
- Avoid duplication
- Smaller
- Removes fixing bugs multiple times
Orthogonality
- Modular
- Separation of concerns
- Testability
- Maintainability
Software Layering
- Pragmatic approach to orthoginality
- Can re-use code more by allowing higher layers to be built from lower layer components
- Avoiding inversion of control
Referential Transparency
- Do not mutate the input or global or internal state
- Avoids side-effects
- Same input means same output
- Testability
- Maintainability
- Scalability - Concurrent
Test driven development
- Given a specification of what you want a module to do, then
- write tests that assert that each requirement is met, then
- write the code to pass all the tests
Data oriented design
- This is in contrast to object oriented design
- Basic idea is that many computational tasks are not bottlenecked by the CPU the bottleneck is accessing memory. RAM access is vastly slower than calculations.
- Rearranging layout of data to improve locality of access can yield speed improvements greater than an improved algorithm that on apearances is computationally less expensive.