Key principle of software architecture
This document discusses several key principles of software architecture: - Separation of concerns breaks applications into distinct features that overlap functionality as little as possible to optimize individual features independently. - The single responsibility principle assigns each component a specific feature to make components cohesive and easier to optimize if features change. - The principle of least knowledge states components should not know internal details of other components to make them cohesive and easier to optimize if features change. - The DRY principle avoids duplicating functionality across components to simplify changes and prevent inconsistencies. - Avoiding big upfront design allows for agile evolution if requirements are unclear.
Key principle of software architecture
- 1. Key Principle of Software Architecture Lilian Codreanu @clipro
- 2. Separation of concerns Break your application into distinct features that overlap in functionality as little as possible. The main benefit of this approach is that a feature or functionality can be optimized independently of other features or functionality.
- 3. Separation of concerns Break your application into distinct features that overlap in functionality as little as possible. The main benefit of this approach is that a feature or functionality can be optimized independently of other features or functionality.
- 4. Single Responsibility Principle Each component or a module should be responsible for only a specific feature or functionality. This makes your components cohesive and makes it easier to optimize the components if a specific feature or functionality changes.
- 5. Principle of least knowledge A component or an object should not know about internal details of other components or objects. Also known as the Law of Demeter (LoD). This makes your components cohesive and makes it easier to optimize the components if a specific feature or functionality changes.
- 6. Dont Repeat Yourself (DRY) There should be only one component providing a specific functionality; the functionality should not be duplicated in any other component. Duplication of functionality within an application can make it difficult to implement changes, decrease clarity, and introduce potential inconsistencies.
- 7. Avoid doing a big design upfront (BDUF) If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. Doing some initial up front modeling, it's just that you are doing so in an effective and agile manner. Create very slim, high-level models early in the project which overview the scope of the effort and identify a likely architectural strategy.
- 8. Prefer composition over inheritance Wherever possible, use composition over inheritance when reusing functionality because inheritance increases the dependency between parent and child classes, thereby limiting the reuse of child classes. With composition, it's easy to change behavior on the fly with Dependency Injection / Setters. Inheritance is more rigid as most languages do not allow you to derive from more than one type.