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.

• Builder

Constructs complex objects using step-by-step approach.

• Factory Method

 Creates an instance of several derived classes.

• Prototype,

 Creates a new object from an existing object.

• Singleton,

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.

• Bridge

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

• Composite

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

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

• Proxy

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.

• Command.

Creates objects which encapsulate actions and parameters.

• Interpreter.

Implements a specific language.

• Iterator.

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

• Mediator.

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

• Memento.

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

• Observer.

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

• State.

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

• Strategy.

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

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

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

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

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

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

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/

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.