... |
... |
@@ -7,84 +7,54 @@ |
7 |
7 |
|
8 |
8 |
|**Term**|(% style="text-align:justify" %)**Explanation** |
9 |
9 |
|Abstraction|(% style="text-align:justify" %)((( |
10 |
|
-1. The opposite of "Concretion". It refers to interfaces and abstract classes that define behavior, namely function signatures, but contain no information about the internal operation of the functions. |
11 |
|
-1. A generic, high-level unit. For example, a class may have two functions that contain duplicate code, which the DRY principle says should not happen. The duplication can be resolved by moving the duplicate code to a common function (the "abstraction" of that code) and calling the function where the code was previously located. The duplicated code has been "abstracted". |
|
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 |
+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 |
|
-|Assertion|(% style="text-align:justify" %)Refers to an assertion function which is an essential part of test code. If the input values do not satisfy a particular condition, the test containing the assertion will fail. Example call: "assertEquals(expectedResult, actualResult)". |
14 |
|
-|Aware/Unaware|(% style="text-align:justify" %)Class A contains a source code reference to class B and is therefore aware of class B. If you only read the source code of class A, you would know that there must be a class B. If there was no such reference, class A would be unaware of class B. |
15 |
|
-|Best Practices|(% style="text-align:justify" %)Generally accepted guidelines for increasing your programming productivity. Taking them seriously will save you a lot of pain. |
16 |
|
-|Concretion|(% style="text-align:justify" %)((( |
17 |
|
-It is the counterpart to "abstraction" and is sometimes called "implementation". In OOP it refers to non-abstract classes that could implement methods of interfaces or abstract classes. A concretion defines the internal workings of these abstract functions by providing the "concrete" code. |
18 |
|
-))) |
19 |
|
-|[[Constructor Injection>>doc:Software Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]|(% style="text-align:justify" %)Dependency injection, which is performed by passing a dependency to an instance via a constructor argument. |
|
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)'. |
|
14 |
+|Awareness|(% style="text-align:justify" %)A class A is aware of class B if it contains a reference to class B in its source code. If no such reference exists, class A is unaware of class B. |
|
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 |
+|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 |
+|[[Constructor Injection>>doc:Software 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. |
20 |
20 |
|Component|((( |
21 |
|
-1. In Spring, this is a generic annotation for a bean that does not match any other Spring bean annotation: "@Component". |
22 |
|
-1. In software architecture, it is a module that can be executed independently. It is often compiled and/or compressed into an executable such as a .jar or .exe file. |
|
19 |
+1. In Spring, a generic annotation for a bean that doesn't fit other specific Spring bean annotations: '@Component'. |
|
20 |
+1. In software architecture, a module capable of independent operation, often compiled or packaged into an executable such as a .jar or .exe file. |
23 |
23 |
))) |
24 |
|
-|Daemon|(% style="text-align:justify" %)A program that runs in the background of a computer system, i.e. without a GUI. |
25 |
|
-|Data Structure|(% style="text-align:justify" %)A very simple type of class that contains only data and no logic. For example, a class that has only public fields and no methods. Another form is a class with private fields and simple corresponding getters and setters. |
26 |
|
-|Dependency|(% style="text-align:justify" %)In the context of classes, a dependency is a member field of one class that must be initialized with an instance of another class in order for an instance of the first class to function properly. This initialization is often done by dependency injection. |
27 |
|
-|Dependency Cycle|(% style="text-align:justify" %)For example, an instance of one class requires an instance of another class to be constructed, and vice versa. So both classes need the other dependency to construct an instance. Therefore, it is impossible to construct either instance at all. Always make sure that the dependency graph looks like a directed acyclic graph. |
28 |
|
-|[[Dependency Injection>>doc:Software Architecture.Dependency Injection.WebHome]] (DI)|(% style="text-align:justify" %)A technique in which the dependencies an object needs are injected from the outside, rather than constructed within the class. |
29 |
|
-|Dirty|((( |
30 |
|
-Messy, unreadable, or poorly designed code is referred to as "dirty code". Often associated with code written "quick-and-dirty" due to the time constraints of a software project. |
31 |
|
-))) |
32 |
|
-|Distribution|A version of an OS packaged with specific software and configurations for particular use cases. Examples are Ubuntu, Fedora and Arch Linux, which are based on Linux. |
|
22 |
+|Daemon|(% style="text-align:justify" %)A program running in the background of a system, typically without a GUI. |
|
23 |
+|Data Structure|(% style="text-align:justify" %)A class primarily meant to hold data and provide basic operations to access and manipulate that data. May contain only public fields, or private fields with associated getter and setter methods. |
|
24 |
+|Dependency|(% style="text-align:justify" %)In context of classes, a dependency is an object required by another object to perform its functions. Often, dependencies are provided via [[dependency injection>>doc:Software Architecture.Dependency Injection.WebHome]]. |
|
25 |
+|Dependency Cycle|(% style="text-align:justify" %)A situation where two or more classes depend on each other to be instantiated. This situation creates a circular dependency that makes object creation impossible. The dependency graph should be a directed acyclic graph rather than a cycle. |
|
26 |
+|[[Dependency Injection>>doc:Software Architecture.Dependency Injection.WebHome]] (DI)|(% style="text-align:justify" %)A technique where an object's dependencies are provided from outside, rather than being created within the object itself. |
|
27 |
+|Dirty|Code that is messy, unreadable, or poorly designed. Often refers to 'quick-and-dirty' code written under time pressure. |
|
28 |
+|Distribution|A version of an OS packaged with specific software and configurations, designed for specific use cases. Examples: Ubuntu, Fedora, and Arch Linux, all based on Linux. |
33 |
33 |
|Dynamic|((( |
34 |
|
-(% style="text-align: justify;" %) |
35 |
|
-Often refers to processes that appear at run time when the code has already been executed and is "running". Examples: |
36 |
|
- |
37 |
|
-* Dynamic dependencies are dependencies that can be replaced at runtime. |
38 |
|
-* Dynamically typed languages determine the type of an object at runtime. |
|
30 |
+Pertains to behaviors or properties determined at runtime. Examples: dynamic dependencies can be replaced at runtime; dynamically-typed languages determine an object's type at runtime. |
39 |
39 |
))) |
40 |
40 |
|Entity|((( |
41 |
41 |
(% style="text-align: justify;" %) |
42 |
|
-~1. In an object context, this means that two objects of the same type that contain exactly the same values in their fields can be considered equivalent, but are still two separate entities. |
|
34 |
+~1. In object context, this signifies that two objects of the same type, even with identical field values, are still distinct entities. |
43 |
43 |
|
44 |
44 |
(% style="text-align: justify;" %) |
45 |
|
-2. In the context of software architecture, the term refers to classes that represent the data model of the application. For example, a banking application may have entity classes such as //account//, //order//, //customer//, or //employee//. |
|
37 |
+2. In software architecture, refers to classes representing application data models. A banking application might have entity classes like Account, Order, Customer, or Employee. |
46 |
46 |
))) |
47 |
|
-|[[Field Injection>>doc:Software Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]|(% style="text-align:justify" %)A type of dependency injection that is performed by forcibly injecting a dependency into an instance through the use of reflections that break even the encapsulation of private fields. |
48 |
|
-|Graphical User Interface (GUI)|(% style="text-align:justify" %)A type of user interface that allows the user to interact with the computer by means of graphical elements such as icons, buttons, windows and menus. |
49 |
|
-|[[Inversion of Control>>doc:Software Architecture.Dependency Injection.Dependency Injection Explained.WebHome]] (IoC)|(% style="text-align:justify" %)Shifts the responsibility for defining the logic and order of dependency injections from the developer to the computer. |
50 |
|
-|JavaBean|((( |
51 |
|
-(% style="text-align: justify;" %) |
52 |
|
-A design convention for data structures. Usually it means a class that has |
53 |
|
- |
54 |
|
-* a public no-argument constructor |
55 |
|
-* only private fields |
56 |
|
-* only getters and setters for each field as methods |
57 |
|
- |
58 |
|
-(% style="text-align: justify;" %) |
59 |
|
-Often DTOs and entities follow this convention. |
60 |
|
-))) |
61 |
|
-|Logic|(% style="text-align:justify" %)Any code with non-trivial complexity can be called 'logic'. In contrast, for example, getters and setters have trivial complexity. |
62 |
|
-|Magic|(% style="text-align:justify" %)'Code that handles complex tasks while hiding that complexity to present a simple interface.'^^[[~[source~]>>url:https://en.wikipedia.org/wiki/Magic_(programming)]]^^ |
63 |
|
-|Operating System (OS)|(% style="text-align:justify" %)((( |
64 |
|
-It is the core system software that controls and coordinates all of the computer's resources. Examples are Windows, Mac OS and Linux. |
65 |
|
-))) |
66 |
|
-|Pain|(% style="text-align:justify" %)Something causes pain when someone spends unnecessary effort on a task that could often have been avoided by better code design. |
67 |
|
-|Production Code|(% style="text-align:justify" %)The counterpart to the Test Code. It contains all the code needed to run the application. |
68 |
|
-|Rollback|The process of reverting a system or data to a previous snapshot. |
69 |
|
-|Runtime|'At runtime' means the period of time during which the code is executed. |
70 |
|
-|Separation of Concerns|(% style="text-align:justify" %)A principle that says that software should be structured modular, with each module dealing with a different aspect of the program. This is intended to give the software a clear, understandable architecture. |
71 |
|
-|[[Setter Injection>>doc:Software Architecture.Dependency Injection.Types of Dependency Injection.WebHome]]|(% style="text-align:justify" %)A type of dependency injection, which is performed by passing a dependency to an instance via a setter method argument. |
72 |
|
-|Snapshot|A snapshot is a copy of a system or data at a specific point in time. It enables 'rollbacks' that can be used to revert to that state in the future if needed. |
|
39 |
+|[[Field Injection>>doc:Software 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 |
+|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 |
+|[[Inversion of Control>>doc:Software 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 Architecture.Dependency Injection.WebHome]]. An IoC container, as found in the Spring Framework, is a common tool for implementing this principle. |
|
42 |
+|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. |
|
43 |
+|Logic|(% style="text-align:justify" %)Code with non-trivial complexity. For instance, getters and setters have trivial complexity and are usually not considered 'logic'. |
|
44 |
+|Magic|(% style="text-align:justify" %)Code that performs complex tasks while abstracting away the complexity, presenting a simple interface to the user. |
|
45 |
+|Operating System (OS)|(% style="text-align:justify" %)The foundational system software that manages and coordinates all computer resources. Examples include Windows, MacOS, and Linux. |
|
46 |
+|Pain|(% style="text-align:justify" %)An unpleasant experience caused by unnecessary efforts that could be mitigated with better code design. |
|
47 |
+|Production Code|(% style="text-align:justify" %)Code that comprises the functioning part of an application, as opposed to test code. |
|
48 |
+|Rollback|The act of returning a system or data to a previous state, often using a snapshot. |
|
49 |
+|Runtime|The period when the code is being executed. |
|
50 |
+|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. |
|
51 |
+|[[Setter Injection>>doc:Software 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. |
|
52 |
+|Snapshot|A saved state of a system or data at a specific point in time. Can be used for rollbacks. |
73 |
73 |
|Spring Bean|((( |
74 |
|
-(% style="text-align: justify;" %) |
75 |
|
-A term used in the Spring Framework for an object that is contained in the IoC container to be injected into other beans and/or to receive dependency injections. It is one of many components/beans that are wired together via IoC to form the application when it is started. |
76 |
|
- |
77 |
|
-(% style="text-align: justify;" %) |
78 |
|
-It should not be confused with JavaBeans. |
|
54 |
+An object managed within the Spring Framework's IoC container, which can be injected into other beans or receive injections itself. It contributes to the application's functionality upon startup and should not be confused with JavaBeans. |
79 |
79 |
))) |
80 |
|
-|Static|((( |
81 |
|
-(% style="text-align: justify;" %) |
82 |
|
-Often refers to processes that depend on non-running code. Examples: |
83 |
|
- |
84 |
|
-* Static code analysis tools can examine source code files for possible improvements. |
85 |
|
-* Statically typed languages determine the type of an object at compile time. |
86 |
|
-))) |
87 |
|
-|Test Code|(% style="text-align:justify" %)The counterpart to the Production Code. It is code that checks that the production code works as expected. Test code has no role in the operation of an application. |
88 |
|
-|Test-Driven Development (TDD)|(% style="text-align:justify" %)A workflow in which the developer implements code in small steps, incrementally and iteratively, defining tests at each iteration. |
89 |
|
-|Virtual Machine (VM)|(% style="text-align:justify" %)A software emulation of a physical computer that can run its own OS and applications as if it were a separate physical machine. |
90 |
|
-|Wiring|(% style="text-align:justify" %)The process of generating and injecting dependencies to start an application, performed by the IoC container. |
|
56 |
+|Static|Pertains to behaviors or properties determined at compile time. Examples: static code analysis tools inspect source code; statically-typed languages determine an object's type at compile time. |
|
57 |
+|Test Code|(% style="text-align:justify" %)Code that tests the functionality of production code. Does not contribute to the operational aspects of an application. |
|
58 |
+|Test-Driven Development (TDD)|(% style="text-align:justify" %)A development approach where code is written in small increments, with tests defining functionality written before each coding iteration. |
|
59 |
+|Virtual Machine (VM)|(% style="text-align:justify" %)A software emulation of a physical computer, able to run its own OS and applications as if it were a separate physical machine. |
|
60 |
+|Wiring|(% style="text-align:justify" %)The process conducted by the IoC container to create and inject dependencies, facilitating application startup. |