Changes for page Glossary

Last modified by chrisby on 2024/09/19 10:50

From version 25.1
edited by chrisby
on 2024/09/19 10:50
Change comment: Renamed back-links.
To version 24.1
edited by chrisby
on 2024/09/19 10:50
Change comment: Renamed back-links.

Summary

Details

Page properties
Content
... ... @@ -15,7 +15,7 @@
15 15  | Clean Code | A term coined by Robert C. Martin, see [[book recommendations|doc:Main.Recommended Books.WebHome]]. It means code that is readable, which means easy to understand and also maintainable, which means easy to change. |
16 16  | Compile Time | The period when the code is compiled. Often used to distinguish from runtime. |
17 17  | Concretion | The counterpart to 'abstraction'. Concretion is also known as 'implementation'. In OOP, it 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. |
18 -| [[Constructor Injection|doc:Software Engineering.Hidden.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection in which dependencies are provided to an object through constructor arguments. |
18 +| [[Constructor Injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection in which dependencies are provided to an object through constructor arguments. |
19 19  | 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 have a CLI. |
20 20  | Commitment | A binding promise from one person to another to complete a specific task within a specified period of time. |
21 21  | Component | Often used to refer to a set of units, modules, or "architectural" components without a clearer specification. In software architecture, it refers to a module capable of independent operation, often compiled or packaged into an executable such as a `.jar` or `.exe` file. |
... ... @@ -34,7 +34,7 @@
34 34  | Dynamic | Behaviors/properties determined at runtime. Examples: dynamic dependencies can be replaced at runtime; dynamically-typed languages determine an object's type at runtime. |
35 35  | Entity | 1) In the OOP context, this means that two separately constructed objects of the same type, even with identical field values, are still distinct entities. 2) In software architecture, refers to classes representing application data models and core business logic. A banking application might have entity classes like Account, Order, Customer, or Employee with methods like `myCustomer.executeOrder(someOrder)`. |
36 36  | Estimates | Intelligent guesses about the resources needed to complete a user story. It is not a binding promise as opposed to a commitment. |
37 -| [[Field Injection|doc:Software Engineering.Hidden.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection where a dependency is injected directly into an object's field via reflection, bypassing encapsulation. |
37 +| [[Field Injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection where a dependency is injected directly into an object's field via reflection, bypassing encapsulation. |
38 38  | Flag Argument | A flag argument is a boolean parameter passed to a function, signaling it to perform a specific operation or change its behavior based on the flag's true or false value. |
39 39  | Functionality / Feature | An operation that a system can perform from the user's point of view. For example, the "login" functionality/feature on a website. |
40 40  | Graphical User Interface (GUI) | A user interface that allows users to interact with the system through graphical elements like icons, buttons, windows, and menus. |
... ... @@ -74,7 +74,7 @@
74 74  | Security | Measures implemented to protect systems from threats, unauthorized access, and vulnerabilities. This includes, but is not limited to, authentication, authorization, and encryption. |
75 75  | Self-Containment | 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. |
76 76  | Separation of Concerns | A design principle suggesting that each module or component should have a single responsibility or concern, enhancing clarity and maintainability. |
77 -| [[Setter Injection|doc:Software Engineering.Hidden.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection where a dependency is provided to an object through a setter method. |
77 +| [[Setter Injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection where a dependency is provided to an object through a setter method. |
78 78  | Snapshot | A saved state of a system or data at a specific point in time. Can be used for rollbacks. |
79 79  | Software Engineer | Technical expert with in-depth knowledge in many areas, including high-level topics such as software architecture and system design. |
80 80  | Solution Domain | The language/terminology used by technical experts to describe the technical solutions to the software requirements defined by the problem domain. |