... |
... |
@@ -7,7 +7,7 @@ |
7 |
7 |
|
8 |
8 |
|**Term**|(% style="text-align:justify" %)**Explanation** |
9 |
9 |
|Abstraction|(% style="text-align:justify" %)((( |
10 |
|
-1. The counterpart to 'Concretion', refers to interfaces and abstract classes that define behavior (function signatures) but leave the internal operacommand-line interfacestion of these functions undefined. |
|
10 |
+1. The counterpart to 'Concretion', refers to interfaces and abstract classes that define behavior (function signatures) but leave the internal operation of these functions undefined. |
11 |
11 |
1. A higher-level, generalized unit of code. Duplication across multiple functions can be resolved by creating an 'abstraction' - a separate function containing the shared code. This adheres to the DRY principle. |
12 |
12 |
))) |
13 |
13 |
|Assertion|(% style="text-align:justify" %)Pertains to an assertion function, a crucial part of testing. If the input values don't satisfy a certain condition, the test containing the assertion fails. Example: 'assertEquals(expectedResult, actualResult)'. |
... |
... |
@@ -15,7 +15,6 @@ |
15 |
15 |
|Best Practices|(% style="text-align:justify" %)Widely accepted guidelines designed to enhance programming productivity and code quality. Adherence can prevent many potential issues. |
16 |
16 |
|Concretion|(% style="text-align:justify" %)The counterpart to 'abstraction', also known as 'implementation'. In OOP, refers to non-abstract classes that implement the methods of interfaces or abstract classes. A concretion provides the 'concrete' code defining the workings of these abstract functions. |
17 |
17 |
|[[Constructor Injection>>doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]|(% style="text-align:justify" %)A type of dependency injection in which dependencies are provided to an object through constructor arguments. |
18 |
|
-|Command-Line Interface (CLI)|"[...] a means of interacting with a computer program by inputting lines of text [...]".^^~[[[src>>https://en.wikipedia.org/wiki/Command-line_interface]]]^^ For example, tools/commands used when working with a (Linux) terminal. |
19 |
19 |
|Component|((( |
20 |
20 |
1. In Spring, a generic annotation for a bean that doesn't fit other specific Spring bean annotations: '@Component'. |
21 |
21 |
1. In software architecture, a module capable of independent operation, often compiled or packaged into an executable such as a .jar or .exe file. |
... |
... |
@@ -39,7 +39,7 @@ |
39 |
39 |
))) |
40 |
40 |
|[[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. |
41 |
41 |
|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. |
42 |
|
-|[[Inversion of Control>>doc:Software Engineering.Architecture.Dependency Injection.Dependency Injection Explained.WebHome]] (IoC)|(% style="text-align:justify" %)A design principle that delegates a program's control flow to a separate container or framework that "wires" application components together, facilitating [[dependency injection>>doc:Software Engineering.Architecture.Dependency Injection.WebHome]]. An IoC container, as found in the Spring Framework, is a common tool for implementing this principle. |
|
41 |
+|[[Inversion of Control>>doc:Software Engineering.Architecture.Dependency Injection.Dependency Injection Explained.WebHome]] (IoC)|(% style="text-align:justify" %)A design principle that delegates a program's control flow to a separate container or framework that "wires" application components together, facilitating [[dependency injection>>doc:Software Engineering.Dependency Injection.WebHome]]. An IoC container, as found in the Spring Framework, is a common tool for implementing this principle. |
43 |
43 |
|JavaBean|A design convention for data structures. Typically, a class with a public no-argument constructor, private fields, and getter/setter methods for each field. Often followed by DTOs and entities. |
44 |
44 |
|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. |
45 |
45 |
|Logic|(% style="text-align:justify" %)Code with non-trivial complexity. For instance, getters and setters have trivial complexity and are usually not considered 'logic'. |