Summary Second Period

So far we have been seeing a lot of different things this second period. So it is important to make a summary of all that topics that covered this second period. In this occasion the second record exam will cover the following topics:

1. Design Patterns covered in the theory book.
2. Microservices.
3. SOLID principles.
4. The 4+1 view model.

As I said earlier, this blog entry will be a summary of all these topics but I encourage you to see all your notes, programming activities and even read again the theory book of Olsen.

Design Patterns

Design Patterns are typical solutions to commonly occurring problems in software design. These patterns were proposed by the Gang of Four: Erich Gamma, John Vlissides, Ralph Johnson and Richard Helm.

Template Method Pattern

The Template Method Pattern is a behavioral design pattern that defines a skeleton of an algorithm in the superclass but lets subclasses override specific steps of the algorithm without changing its structure. In this kind of pattern you use the inheritance property of Object Oriented Programming (OOP).

Strategy Pattern

The Strategy pattern is a behavioral design pattern that turns a set of behaviors into objects and makes them interchangeable inside original context object. An example of this pattern is the activity we did in class (specifically the strategy.rb and strategy_test.rb), in this example all the method we create are interchangeable because we define a different method doing different stuff with the data that the object Student has.

Observer Pattern

The Observer Pattern provides a way to subscribe and unsubscribe to and from these events for any object that implements a subscriber interface. This pattern was made in the second programming activity of the course (if you have any doubt I encourage you to do again the programming activity or only check it out).

Composite Pattern

Composite is a structural design pattern that lets you compose objects into tree structures and then work with these structures as if they were individual objects. Using this pattern makes sense when the core model of your app can be represented as a tree. An example of this pattern is a military structure.

Iterator Pattern

Iterator is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representations (list, stack, tree, etc.). It exists two kind of iterators that we can use when we consider using the Iterator pattern. The first one, external iterator takes this name because the iterator is a separate object from the aggregate; the second one, internal iterators takes this name because all of the iterating action occurs inside the aggregate object.

Command Pattern

Is a behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation lets you parameterize methods with different requests, delay or queue a request's execution, and support undoable operations.

Adapter Pattern

Adapter is a structural design pattern that allows objects with incompatible interfaces to collaborate. An example of this pattern is all the different power plugs that exists in the whole world in USA it is one type and in Europe it is another power plugs; so, in order to charge your phone you need a power plug adapter for Europe.

Proxy Pattern

Is a structural design pattern that lets you provide a substitute or placeholder for another object. A proxy controls access to the original object, allowing you to perform something either before or after the request gets through to the original object. An example of this pattern is a proxy for a bank account, which is a proxy for a bundle of cash.

Decorator Pattern

Is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors. The best example of this pattern is the one that was covered in the programming activity, a coffee can have a lot of different condiments that will change the name of the beverage and the cost of this.

Singleton Pattern

Is a creational design pattern that lets you ensure that a class has only one instance, while providing a global access point to this instance. An example of this pattern is the following one, the government of a country is an excellent example. A country can have only one official government.

Factory Pattern

Is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created. An as they say, an image says more than thousand words; the example is the following one:

Builder Pattern

Is a creational pattern that lets you construct complex objects step by step. The pattern allows you to produce different types and representations of an object using the same construction code. Also, this image tells us an excellent example:

Interpreter Pattern

It is a pattern where you have to construct an Abstract Syntax Tree with its corresponding language that will be the rules that you will need to follow. The best way to understand this pattern is thinking about compiler course and having in mind that the first three phases of the compiler in the AST creation you can program the behavior in order to produce a interpretation of language A into language B.

Domain Specific Language Pattern

This pattern suggests you that you should focus on the language itself, not on the interpreter. It says that sometimes you can make problems easier to solve by giving the user a convenient syntax for expressing the problem in the first place.

Meta-programming Pattern

This pattern focuses on leveraging the flexibility of Ruby. This pattern suggests us to take advantage of the dynamic behaviors as an alternative way to access objects that we need.

Convention over Configuration Pattern

This pattern focuses on applying the next principles when developing applications and frameworks:

1. Attempt to anticipate the user's needs.
2. Don't make the user repeat himself or herself.
3. Provide a starter template.

Microservices

We can define Microservices as an architectural style which approach is to develop a single application as a suite of small services, each of them, running its own processes and communicating via lightweight mechanisms, often Microservices uses an HTTP resource API. Microservices have some important characteristics that we will describe

Components via Services

Will use libraries, but their primary way of componentizing their own software is by breaking down into services.

Organized around Business Capabilities

The Microservices approach splits up into services organized around the business capability.

Products not Projects

Microservices proponents tend to avoid the project model, preferring instead the notion that a team should own a product over its full lifetime.

Smart endpoints and dumb pipes

Microservices applications aim to be as decoupled and as cohesive as possible, they own their own logic, receiving a request, applying a logic as appropriate and producing a response.

Decentralized Governance

Use the right tool for the job while monolithic applications cannot  take advantage of different languages to a certain extent.

Decentralized Data Management

Each service manages its own database, either different instances of the same database technology, or entirely different database systems.

Infrastructure automation

Aws has reduced the operational complexity of building and deploying and operating microservices.

Design for failure

It is a kind of automated testing in production.

Evolutionary Design

Only a few modules or services might need to evolve in this case if you have more than one module that you constantly need to evolve it, these two services should be merged.

SOLID Principles

SOLID is an acronym that stands for 5 principles of object-oriented programming and design. The objective of these principles is the avoidance of dependencies, because the more things you depend on, the greater the change something will go definitively wrong.

S => Single Responsibility Principle (SRP)

States that a class should have exactly one responsibility. This means, that it should have exactly one reason that cause it to be changed.

O => Open/Close Principle (OCP)

States that a class (or function) should have the following behavior; should be open for extension but close for modification. This principle attempts to counter the tendency for OO code to become fragile or easily broken.

L => Liskov Substitution Principle (LSP)

Imply that you should avoid modifying the behavior of a base class, but Liskov forbids modification of that behavior through the mechanism of inheritance.

I => Interface Segregation Principle (ISP)

Avoid writing monstrous interfaces that burden classes responsibilities they don't need or want. Instead, create a collection of smaller, discrete interfaces, partitioning interface members according to what they concern

D => Dependency Inversion Principle (DIP)

Depend upon abstractions, not upon concretions. Instead of writing code that refers to actual classes, you should instead write code that refers to interfaces or perhaps abstract classes.

The 4+1 View Model

This model consists in 5 different views that will help us to develop new projects or applications. The views that covers are the following ones:

Logical View

Shows the parts that comprise the system, as well as their interactions. This model can be represented with UML class diagramas, state diagrams, object diagrams and sequence diagrams.

Process View

Describes a system's process. It also shows any communication between those processes, explores what needs to happen inside the system.  It is helpful when your system haves a number of simultaneous threads or processes. This model can be represented with UML activity diagrams.

Physical View

Models the system's execution environment. Also maps software artifacts onto the hardware that host them. This model can be represented with UML Deployment diagrams.

Development View

Describes the system's modules, or components, including packages, subsystems, and class libraries. This view can be represented with UML component diagram and package diagram.

Use case View

Shows system's functionality by capturing user goals and scenarios. It offers an outside-world perspective on the system. This view can be represented with UML use case diagrams.