Architectural patterns

Architectural Patterns.

These architecture patterns are a reusable solution to a commonly occurring problem within the field of software design. Software architecture patterns are a description or template for the structural organization or scheme for how to solve a problem that can be used in many different situations.

  1. Layered pattern

This pattern can be used to structure programs that can be divided into groups of subtasks, each of which is at a particular level of abstraction. Each layer provides services to the next higher layer.

Layers of a general information system:

  • Presentation layer 
  • Application layer 
  • Business logic layer
  • Data access layer 

Usage

  • General desktop applications.
  • E commerce web applications.

2. Client-server pattern

Consists of two parties; server and multiple clients. The server component will provide services to multiple client components. Clients request services from the server and the server provides relevant services to those clients.

Usage

  • Online applications such as email, document sharing and banking

4. Pipe-filter pattern

This can be used to structure systems which produce and process a stream of data. Each processing step is enclosed within a filter component. Data to be processed is passed through pipes.

Usage

  • Compilers. The consecutive filters perform lexical analysis, parsing, semantic analysis, and code generation.
  • Workflows in bioinformatics.

5. Broker pattern

It’s used to structure distributed systems with decoupled components. These components can interact with each other by remote service invocations.

Usage

6. Peer-to-peer pattern

In this pattern, individual components are known as peers. Peers may function both as a client, requesting services from other peers, and as a server, providing services to other peers.

Usage

7. Event-bus pattern

This pattern primarily deals with events and has 4 major components; event source, event listener, channel and event bus. Sources publish messages to particular channels on an event bus. Listeners subscribe to particular channels. Listeners are notified of messages that are published to a channel to which they have subscribed before.

Usage

  • Android development
  • Notification services

9. Blackboard pattern

This pattern is useful for problems for which no deterministic solution strategies are known. The blackboard pattern consists of 3 main components.

  • blackboard — a structured global memory containing objects from the solution space
  • knowledge source — specialized modules with their own representation
  • Control component — selects, configures and executes modules.

Usage

  • Speech recognition
  • Vehicle identification and tracking
  • Protein structure identification
  • Sonar signals interpretation.

10. Interpreter pattern

This pattern is used for designing a component that interprets programs written in a dedicated language. It mainly specifies how to evaluate lines of programs, known as sentences or expressions written in a particular language.

Usage

  • Database query languages such as SQL.
  • Languages used to describe communication protocols.

REFERENCE

DESIGN PRINCIPLE

DESIGN PATTERNS.

Design patterns provide a comprehensive solution that can be reused for common problems that arise in software design. A design pattern isn’t a complete design that can be transformed directly into code.

Types of Design Patterns:

  • Creational Design Patterns
    Creational Patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. They reduce complexity and instability by creating objects in a controlled manner.

Types of CDP:

  1. Abstract Factory

Creates families of related dependent objects.

Constructs complex objects using step-by-step approach.

 Creates an instance of several derived classes.

 Creates a new object from an existing object.

A class of which only a single instance can exist.

  • Structural Design Pattern

These design patterns are concerned with arranging different classes and objects to create larger structures and provide new functionality. Structural class-creation patterns use inheritance to create interactions/interfaces.

Types of SDP:

  1. Adapter

Allows for two incompatible classes to work together by wrapping an interface around one of the existing classes.

Separates the outline so that the two classes can differ on their own.

Composite patternconsider a group of objects to be one.

  • Decorator
    Allows for an object’s behavior to be extended dynamically at run time.
  • Facade

Provides a simple interface to a more complex underlying object.

Flyweight pattern takes the weight, or memory footprint, off of our objects by recycling them.

This pattern offers a proxy, or a substitute, to another complex object. Provides a space interface for the primary object to control access, reduce costs, or reduce complexity.

  • Behavioral Design Patterns

Behavioral patterns are about identifying common patterns of communication between objects and identifying these patterns.

Types of BDP:

  1. Chain of Responsibility.

Delegates commands to a chain of processing objects.

Creates objects which encapsulate actions and parameters.

Implements a specific language.

It accesses the elements of an object in sequence without revealing its basic representation.

Allows for free integration between classes as it is the only class that has in-depth knowledge of their methods.

Provides the ability to restore an object to its previous state.

 Is a publish/subscription pattern that allows a number of observer objects to see an event.

Allows an object to change its behavior when its internal state changes.

Allows one of a family of algorithms to be selected on-the-fly at run-time.

  1. Template Method.

Defines the framework of the algorithm as an abstract class, allowing its sub-classes to deliver consistent behavior.

  1. Visitor.

Separates an algorithm from an object structure by moving the hierarchy of methods to a single object.

REFERENCE

  1. https://www.geeksforgeeks.org/design-patterns-set-1-introduction/
  2. https://sourcemaking.com/design_patterns

YAGNI

What is YAGNI?

YAGNI – You aren’t gonna need it is an Extreme Programming (XP) key practice that’s states: “Always implement things when you actually need them, never when you just foresee that you need them.”As it stated then programmer should not add functionality until it is proven to be absolutely necessary

YAGNI Principle always recommends programmers to build the easiest solution to today’s problems. Even if you are sure you will need the feature, moreover, do not run it now. Mostly, it’ll alter in either:

  1. You won’t need it after all, or
  2. What you really need is different from what you originally thought.

Why YAGNI Principle is mostly relevant in Software Development Lifecycle than others?

In Software Development when software developers start implementing features they always go into practices known as FEATURE CREEP. Software developers always try to add or improve features regardless of whether they are not requested by users. For example, developers may try to add authentication to the form without first completing CRUD in the database.

Alternatively, following YAGNI in the configuration life cycle enables developers to implement features that will only be relevant for the first duplicate or demo and other future features that will work as a new version or update of software developed as recommended by users.

YAGNI Principle is safe, if …

The YAGNI principle, alone, may not be secure. Software developers can set up an early algorithm on the system and then copy-paste it all over, so when it goes wrong they spend a lot of effort fixing it. With this process in coding, YAGNI is very dangerous and may not be the best idea.

But when the developers set the quality of the design, the quality of the code, and the quality of the test, YAGNI is completely safe, as every future risk is excluded by simple design rules, and it will be easy to find and fix if it goes wrong.

Benefits of YAGNI:

  • With a simple answer you can say the biggest benefit of the YAGNI Principle is to avoid unnecessary development.

Main reasons to practice YAGNI

1. It saves time as you avoid writing code that may not make sense later.

2. Your current code is better because you avoid guessing which can be bad

For two main reasons for practice, they ensure:

• That deadlines are available quickly,

• Customer satisfaction due to visible and frequent changes according to their needs or details,

• The best quality of code ordered by the fact that developers focus on small tasks (those that are currently very important),

• The code can be extended more and more (allows for updated versions),

• Reduced number of adjustments required,

• That the error is easy to fix.

REFERENCE: – 

https://deviq.com/principles/yagni

OBJECT ORIENTED PROGRAMMING

OBJECT ORIENTED PROGRAMING:

Object-Oriented Programming (OOP) is all about creating “objects”. An object is a group of variables and related functions. These variables are often referred to as properties of the object and functions are referred to as the behavior of the objects. These objects provide the best and most straightforward software design.

Principles of OOP.

Object-oriented programming is based on the following principles:

  • Encapsulation. 

This principle states that all important information is in the object and only selected information is disclosed. The implementation and state of each object is done privately within a specific class. Other objects do not have permission to access this class or the authority to make changes. This characteristic of data encryption provides more software security and avoids unexpected data corruption.

  • Abstraction

Objects only display internal mechanisms that are necessary for the use of other objects, to hide any unnecessary implementation code. The resulting class can be extended its functionality. This concept can help developers to make additional changes or additions more easily over time.

  • Inheritance.

Classes can reuse code from other classes. Relationships and small bridges between objects can be handed over, enabling developers to reuse common logic while continuing to maintain a unique bridge. This OOP property compels more detailed data analysis, reduces processing time and ensures a high degree of accuracy.

  • Polymorphism.

 Objects are designed to share behavior and can take up more than one form. The program will determine what meaning or use is necessary for each implementation of an item from the parent class, thus reducing the need to repeat the code. Then a child class is created, which enhances the functionality of the parent class.

Advantages of using OOP

  1. OOP Allows parallel development.

If you are working with software teams, then everyone can work independently once the standard classes have been resolved. That allows a relative level of parallel growth that would not have been achieved otherwise.

  • Module classes can be used again and again.

Once module classes are created, they can be reused in programs or other projects. Sometimes, little-to-no adjustments are necessary for the next project. That gives the team more flexibility as it crosses the starting point.

  • Coding is easy to maintain.
  • With OOP, because your coding is centralized, it is easy to create a code that can be maintained. That makes it easier to store your data when you need to make updates.

Disadvantages of using OOP.

  1. It can be ineffective.

Targeted programming tends to use more CPUs than alternative options. That can make it an inconvenient option when there are technical limitations involved because of the size that can be exhausted. Because of the duplication involved, the initial coding may be larger than the other options as well.

  • It can be very large.

If OOP is left unchecked, then it can create a large number of complete, unwanted code. When that happens, costs go up and that makes it harder to keep costs down.

 

REFERENCES:

  1. https://info.keylimeinteractive.com/the-four-pillars-of-object-oriented-programming
  2. https://medium.com/@cancerian0684/what-are-four-basic-principles-of-object-oriented-programming-645af8b43727

THE SOLID

SOLID

 SOLID is an acronym that stands for five key design principles: Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle. All five are used by software engineers and provide significant benefits to developers.

 

Principles of SOLID:

  • SRP – Single Responsibility Principle

SRP states that, “a class should have one, and only one, reason to change.” Following this principle means that each class does only one thing and each class or module is responsible for only one part of the program functionality. For simplicity, each class should solve only one problem.

Single responsibility principle is a basic principle that many developers already use to create code. It can be used for classes, software components, and sub-services.

Applying this principle simplifies testing and maintaining the code, simplifies software implementation, and helps prevent unintended consequences of future changes.

  • OCP – Open/Closed Principle

OCP states that software entities (classes, modules, methods, etc.) should be open for extension, but closed for modification.

Practically this means creating software entities whose behavior can be changed without the need to edit and compile the code itself. The easiest way to demonstrate this principle is to focus on the way it does one thing.

  • LSP – Liskov Substitution Principle

LSP states that “any subclass object should be substitutable for the superclass object from which it is derived”.

While this may be a difficult principle to put in place, in many ways it is an extension of a closed principle, as it is a way to ensure that the resulting classes expand the primary class without changing behavior.

  • ISP – Interface Segregation Principle

ISP principle states that “clients should not be forced to implement interfaces they do not use.”

Developers do not just have to start with an existing interface and add new techniques. Instead, start by creating a new interface and then let your class implement as many interactions as needed. Minor interactions mean that developers should prefer composition rather than legacy and by separation over merging. According to this principle, engineers should work to have the most specific client interactions, avoiding the temptation to have one large, general purpose interface.

  • DIP – Dependency Inversion Principle

DIP – Dependency Inversion Principle states that “high level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details.  Details should depend upon abstractions”

This principle offers a way to decouple software modules. Simply put, dependency inversion principle means that developers should “depend on abstractions, not on concretions.”

Benefits of SOLID principle

  • Accessibility
  • Ease of refactoring
  • Extensibility
  • Debugging
  • Readability

REFERENCES:

  1. https://www.bmc.com/blogs/solid-design-principles/