mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 05:03:43 +01:00
Document high-level architecture goals
Create a high-level description of the long-term software architecture goals. Closes ticket 32206.
This commit is contained in:
parent
089466eff3
commit
0fd49c6663
3
changes/ticket32206
Normal file
3
changes/ticket32206
Normal file
@ -0,0 +1,3 @@
|
||||
o Documentation:
|
||||
- Create a high-level description of the long-term software
|
||||
architecture goals. Closes ticket 32206.
|
31
src/arch_goals.md
Normal file
31
src/arch_goals.md
Normal file
@ -0,0 +1,31 @@
|
||||
@page arch_goals High level code design practices
|
||||
|
||||
This page describes the high level design practices for Tor's code.
|
||||
This design is a long-term goal of what we want our code to look like,
|
||||
rather than a description of how it currently is.
|
||||
|
||||
Overall, we want various parts of tor's code to interact with each
|
||||
other through a small number of interfaces.
|
||||
|
||||
We want to avoid having "god objects" or "god modules". These are
|
||||
objects or modules that know far too much about other parts of the
|
||||
code. God objects/modules are generally recognized to be an
|
||||
antipattern of software design.
|
||||
|
||||
Historically, there have been modules in tor that have tended toward
|
||||
becoming god modules. These include modules that help more
|
||||
specialized code communicate with the outside world: the configuration
|
||||
and control modules, for example. Others are modules that deal with
|
||||
global state, initialization, or shutdown.
|
||||
|
||||
If a centralized module needs to invoke code in almost every other
|
||||
module in the system, it is better if it exports a small, general
|
||||
interface that other modules call. The centralized module should not
|
||||
explicitly call out to all the modules that interact with it.
|
||||
|
||||
Instead, modules that interact with the centralized module should call
|
||||
registration interfaces. These interfaces allow modules to register
|
||||
handlers for things like configuration parsing and control command
|
||||
execution. (The config and control modules are examples of this.)
|
||||
Alternatively, registration can happen through statically initialized
|
||||
data structures. (The subsystem mechanism is an example of this.)
|
@ -29,6 +29,8 @@ Tor repository.
|
||||
|
||||
@subpage intro
|
||||
|
||||
@subpage arch_goals
|
||||
|
||||
@subpage initialization
|
||||
|
||||
@subpage dataflow
|
||||
|
Loading…
Reference in New Issue
Block a user