Module memory_management
Aedi, a dependency injection library.
Aedi is a dependency injection library. It does provide a set of containers that do IoC, and an interface to configure application components (structs, objects, etc.)
Aim
The aim of library is to provide a dependency injection solution that is feature rich, easy to use, easy to learn, and easy to extend up to your needs.
D by default comes with garbage collector which is responsible for destruction and deallocation of components that were used, and discarded by the application. Current implementation of garbage collector can be inefficient for cases when many small objects are continously created and destroyed by application. Therefore aedi framework allows users to select what allocation strategy to use for managed components by using std.experimental.allocator library.
To change the allocator used for components in a container, it is possible to
pass new allocator implementation to configure
method as third argument
just like in example below:
with (container .configure("singleton", Mallocator .instance .allocatorObject)) {
// ... registered components with Mallocator as allocator for them
}
The allocator passed in configure
will be used as default implementation.
As alternative syntax it is possible to pass the allocator in a fluent syntax by chaining
along
to configure
with allocator as it's argument. Example
below shows such variant:
with (container .configure("prototype") .along(MmapAllocator .instance .allocatorObject)) {
// ... registered components with Mallocator as allocator for them
}
The default allocator strategy can be overriden per component by directly specifying the
allocator that should be used by registered component using allocator
property
for registered component. Example below shows such use case:
register!Size("size.sedan") // Register a size of a generic "sedan" into container
.set!"width"(200UL)
.set!"height"(150UL)
.set!"length"(500UL)
.allocator(MmapAllocator .instance .allocatorObject); // Change allocator object for this particular component to mmap allocator.
As a consequence to using custom allocation strategies, for all containers, terminate
method should be called when containers lifetime ends (whether at end of application, or during some other
event), otherwise it is not guaranteed that components are finalized correctly, even if they were allocated on
garbage collector.
Functions
Name | Description |
---|---|
drive(car, name)
|
|
main()
|
Interfaces
Name | Description |
---|---|
Engine
|
Interface for engines. |
Classes
Name | Description |
---|---|
Car
|
A class representing a car. |
CarManufacturer
|
A manufacturer of cars. |
DieselEngine
|
A concrete implementation of Engine that uses diesel for propelling. |
ElectricEngine
|
A concrete implementation of Engine that uses electricity for propelling. |
GasolineEngine
|
A concrete implementation of Engine that uses gasoline for propelling. |
Tire
|
Tire, what it can represent else? |
Structs
Name | Description |
---|---|
Color
|
A struct that should be managed by container. |
Size
|
Size of a car. |