The document discusses principles for building plug-in C++ application architectures, including SOLID principles, dependency inversion, component-based design, and using a plugin approach. It emphasizes designing systems such that modules can be changed without breaking the whole system, and components can be reused in different software. Key points are separating core business logic from optional/variable components, defining clear boundaries between components, and depending on abstract interfaces rather than concrete implementations.

1. www.luxoft.com
Ked Maksym
Plug-In C++ Application Architecture

2. www.luxoft.com
What are we going to
talk about?
2
● SOLID principles
● Dependency inversion
● Component based architecture
principles
● Plugins
● Applications

3. www.luxoft.com
Good code vs bad code
3

4. www.luxoft.com
And then you change something..
4

5. www.luxoft.com 5

6. www.luxoft.com
Good system design
could be described as:
6
● Provides ability to change
certain modules without the
breakdown of the whole system
● Relatively easy to understand
● Components can be used in
different software systems

7. www.luxoft.com 7
SOLID Principles
● Single Responsibility principle
An entity in software system must have one and only one reason to change
● Open-Closed principle
An entity should be open for extension but closed for modification.
● Liskov substitution principle
Objects should be replaceable with instances of their subtypes without breaking the program.
● Interface segregation principle
Many client specific interfaces are better than one general-purpose interface
● Dependency inversion principle
One should depend upon abstractions not concretions

8. www.luxoft.com
Dependency inversion
Changes in abstract interface layers correspond to
changes to its concrete implementations. On the
contrary, changes to concrete implementations usually
do not require changes to the interfaces that they
implement. Interfaces must be less volatile than
implementations.

9. www.luxoft.com
This boils down to the following guidelines:
● Don’t refer to concrete classes (refer to abstract interfaces instead)
● Don’t inherit volatile concrete classes (inheritance is the strongest and the most rigid of all source code
dependencies)
● Don’t override concrete functions (you may have to deal with all the dependencies of a function you are going
to override)

10. www.luxoft.com
Component based architecture
Component is a unit of deployment. They are the
smallest units that can be deployed as a part of the
system.

11. www.luxoft.com
Component cohesion
principles
● REP - Reuse/release principle
The granule of reuse is the granule of
release.
● CCP - Common closure principle
Components should contain classes
that change for the same reasons and
at the same time.
● CRP - Common reuse principle
Don’t force users of a component to
depend on things they don’t need.

12. www.luxoft.com
Defining lines between components

13. www.luxoft.com
What is business logic?

14. www.luxoft.com

15. www.luxoft.com

16. www.luxoft.com
Plugin approach
16
The core business rules are kept
separate from, and independent of
those components that are either
optional or that can be
implemented in many different
forms.

17. www.luxoft.com

18. www.luxoft.com
Applications

19. www.luxoft.com

20. www.luxoft.com

21. www.luxoft.com

22. www.luxoft.com

23. www.luxoft.com

24. www.luxoft.com
Thanks!
GitHub:
https://github.com/smartdevicelink/sdl_core