| ... |
... |
@@ -38,12 +38,6 @@ |
| 38 |
38 |
))) |
| 39 |
39 |
|[[Field Injection>>doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]|(% style="text-align:justify" %)A type of dependency injection where a dependency is injected directly into an object's field via reflection, bypassing encapsulation. |
| 40 |
40 |
|Graphical User Interface (GUI)|(% style="text-align:justify" %)A user interface that allows users to interact with the system through graphical elements like icons, buttons, windows, and menus. |
| 41 |
|
-|Isolation/Isolated|(% style="text-align:justify" %)((( |
| 42 |
|
-The opposite of integration. Isolation is the separation of a unit or component from the rest of the system in order to test, develop or understand it independently and ensure that it works correctly without external interference. For example, in unit testing, a single unit is usually tested independently of other units and is isolated from them. |
| 43 |
|
-))) |
| 44 |
|
-|Integration/Integrated|(% style="text-align:justify" %)((( |
| 45 |
|
-The opposite of isolation. Integration is the process of combining different software units or components to work together as a single, cohesive system. For example, component testing is more integrated than unit testing because it involves multiple units working together. Integration testing tests the interaction between two components. |
| 46 |
|
-))) |
| 47 |
47 |
|[[Inversion of Control>>doc:Software Engineering.Architecture.Dependency Injection.Dependency Injection Explained.WebHome]] (IoC)|(% style="text-align:justify" %)A design principle that encourages the delegation of application unit wiring to a computer algorithm that facilitates [[dependency injection>>doc:Software Engineering.Architecture.Dependency Injection.WebHome]], rather than the developer implementing this logic manually. |
| 48 |
48 |
|Module|(% style="text-align:justify" %)A distinct part of a software that encapsulates specific implementation details, such as functions, data structures, classes, interfaces, or even other modules. It exposes a concise API designed to perform specific tasks. These modules are typically crafted for reusability and improved code organization, thereby promoting a modular design. |
| 49 |
49 |
|Logic|(% style="text-align:justify" %)Code with non-trivial complexity. For instance, getters and setters have trivial complexity and are usually not considered 'logic'. |
| ... |
... |
@@ -53,7 +53,6 @@ |
| 53 |
53 |
|Production Code|(% style="text-align:justify" %)Code that comprises the functioning part of an application, as opposed to test code. |
| 54 |
54 |
|Rollback|The act of returning a system or data to a previous state, often using a snapshot. |
| 55 |
55 |
|Runtime|The period when the code is being executed. |
| 56 |
|
-|Security|(% style="text-align:justify" %)Measures implemented to protect systems from threats, unauthorized access, and vulnerabilities. This includes, but is not limited to, authentication, authorization, and encryption. |
| 57 |
57 |
|Self-Containment|(% style="text-align:justify" %)The ability of software to operate independently, without dependence on external services or factors. This characteristic ensures that its results are determined solely by its source code, which promotes stability and consistency. |
| 58 |
58 |
|Separation of Concerns|(% style="text-align:justify" %)A design principle suggesting that each module or component should have a single responsibility or concern, enhancing clarity and maintainability. |
| 59 |
59 |
|[[Setter Injection>>doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]|(% style="text-align:justify" %)A type of dependency injection where a dependency is provided to an object through a setter method. |
