Software design vocabulary

-

My goal here is to do a logical grouping of tech jargon.

Programming paradigm

  • Structural programming [i.e. C language].
  • OOP: object-oriented design [i.e. C++/JAVA/C# etc]
  • Concurrent programming paradigm
    • Functional programming [i.e. Scala, Transactional-based model: Haskell]
    • CSP - Communicating sequential process [i.e. Erlang, MPI]

Solid

First letter full form in SOLID context
S Single responsibility principle (SRP)
O Open Close principle (OCP)
L Liskov's Substitution Principle (LSP)
I Interface Segregation Principle (ISP)
D Dependency Inversion Principle (DIP)

Component principles -

  • Component Cohesion 
    • Reuse/Release Equivalence Principle (REP)
    • Common Closure Principle (CCP)
    • Common Reuse Principle (CRP)
  • Component coupling 
    • Acyclic dependency principle (ADP)
    • Stable dependency principle (SDP)
    • Stable abstraction principle (SAP)

Software design principles -

General Responsibility Assignment Software Patterns (GRASP)

Assign proper responsibility to objects when you create them. This will help you to develop excellent OO design.

  • Creator

    • In order to properly function, it may be necessary to generate instances of additional classes within your primary class. Whose responsibility is that? In what order shall they get created? How will creation take place? we will get answers to those questions in the creator pattern.
    • Consider how effortlessly users can create objects. Design your interface such that it asks the user what they want and instantiates objects based on requirements. Don't let any class, or client code, populate the memory via object creation from any place.

  • Expert 

    • It's important to have a strong understanding of how dependent classes operate, and your class can provide valuable expertise in this area.
    • The expert class is skilled in effectively utilizing the associated classes.

  • Low Coupling

    • If a class has high coupling, 
      • During the maintenance phase, altering the implementation code can lead to it being easily broken.
      • Hard to understand. As we will be associating different modules with direct references.
    • To execute properly, a highly coupled class relies on many other classes.
    • When creating a class, it's important to ensure that adding new features requires minimal modifications to the existing structure. If your code is highly coupled, achieving that is not possible.
    • There are multiple types of relations between classes.
    • Here's how to order the coupling from low to high.
      • Dependency or usage  (Low)
      • Association
      • Composition
      • Inheritance  (High)
    • It is important to ensure that your class has both strong encapsulation and flexibility. Making changes to a class or its APIs should not affect the functioning of other modules.

  • High Cohesion

    • You should have very focused classes. They shall not perform many different functionalities. 
    • The class should have a limited number of behaviors.
    • The problem lies not in having more classes but in having fewer classes that are not focused, which can result in more issues.
    • If your class is doing many different things. Break it! and have different classes. Make sure those different classes shall have minimal, focused functionality.
    • If we follow high cohesion, then the re-usability of code will improve. 

  • Controller

    • The component that will bridge the gap between the UI and your business layer is the controller.
    • When performing transactions, the controller seamlessly connects the user to various modules as needed.
    • It will lower the coupling between UI and business layers. Both can change independently.
    • If you find that it is causing a bottleneck, consider having multiple controllers for different functions.
    • Your UI component shall not talk to core logic directly. That will limit future enhancement and changes. It has to go through the controller. 

  • Polymorphism

    • When dealing with variations, the traditional approach involves using if-else or switch statements. However, this method often results in excessive boilerplate code and can be challenging to modify later on..
    • Adopting new behavioral changes (from open close principle) can be handled easily with the use of polymorphism.

  • Pure Fabrication

    • If we are building a class which has some other objects, and if that other object has no real counterpart, as far as public behavior of that class is concerned. Then there is a possibility that we should not tightly couple the classes. Instead, make another class, and put that object into it, and form another relations between them.
    • It will help to reduce the coupling. Like we are having a place holder kind of class, which will just hold the info but not exposed in public, then put them into the place where it belongs to so that we can increase the reusability and reduce high coupling or say fabricate it.
    • Gof Ex of this are -> Adapter, Command, Strategy, etc.

  • Indirection

    • This is also a technique to reduce the coupling.
    • have an intermediate object sitting in between, which will help you to reduce the coupling between two objects.
    • GoF ex - Adapter, Bridge, Façade, Observer, Mediator 
    • it will sit between two un-like object and enable them to talk and make system operations execute as expected.

  • Protected variations

    • How you will design your system so that, small or significant change in policy will not affect your existing design much?
    • After you understand the system, you will get a high-level ideas, which behavior may change from time to time, for those behaviors, you can use interface and put a dynamic behavior to execute them.
    • Law of Demeter is another name of protected variations.

basic pillars of OOP

  • Abstraction.
  • Encapsulation.
  • Inheritance.
  • Polymorphism.

Types of relationships in OOPS

  • Is-a, relationship.
  • Has-a, Composite relationship 
    • Aggregation.
    • composition
  • Usage, Association relation.
Note - Private inheritance is composite (Has-a) relation.

CPP patterns -

  • NVI     Non-virtual interface idiom
  • Pimpl  Pointer to implementation


Thanks for reading it. To learn more about design patterns and basic design principles, please see my web page.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer
Read more