A Programação Funcional
Por: kebonij • 25/8/2019 • Resenha • 1.863 Palavras (8 Páginas) • 119 Visualizações
# Functional Programming
## Introduction
* FP focuses on **what** should be done, not **how** it should be done
* Software development goal: to produce code that is:
* modular
* understandable and maintainable
* testable
* extensible
* reusable
* highly cohesive
* with low coupling
* with separation of concerns
* FP helps to achieve this goal:
* Writing separate independent functions, which are composed together to produce the final results
* Functional code tends to be cleaner, shorter, and easier to understand
* Independent functions can be unit tested on their own
* Independent functions can be reused
* Functional code is free from side effects, so you do not need to consider the rest of the code when studying a single function
* However, 100% functional code in JS may ignore some language features
* The challenge is to find the correct balance between FP, OOP, declarative and imperative code in order to achieve those goals
## Is Javascript functional?
* Sorta.
> JS can be considered to be functional, because of several features such as first–class functions, anonymous functions, recursion, and closures -- we'll get back to this later. On the other hand, JS has plenty of non–FP aspects, such as side effects (impurity), mutable objects, and practical limits to recursion.
* **Functions as First Class Objects/Citizens**: means that you can do eveything with functions, that you can do with objects (store in variables, pass as arguments etc)
# Functional Programming
## Introduction
* FP focuses on **what** should be done, not **how** it should be done
* Software development goal: to produce code that is:
* modular
* understandable and maintainable
* testable
* extensible
* reusable
* highly cohesive
* with low coupling
* with separation of concerns
* FP helps to achieve this goal:
* Writing separate independent functions, which are composed together to produce the final results
* Functional code tends to be cleaner, shorter, and easier to understand
* Independent functions can be unit tested on their own
* Independent functions can be reused
* Functional code is free from side effects, so you do not need to consider the rest of the code when studying a single function
* However, 100% functional code in JS may ignore some language features
* The challenge is to find the correct balance between FP, OOP, declarative and imperative code in order to achieve those goals
# Prototypal Inheritance in JS
## Classes
- **Class Inheritance:** **A class is like a blueprint — a description of the object to be created.** Classes inherit from classes and **create subclass relationships**: hierarchical class taxonomies.
- In JS, class inheritance is implemented on top of prototypal inheritance, but *that does not mean that it does the same thing*.
- JavaScript’s class inheritance uses the prototype chain to wire the child *`Constructor.prototype`* to the parent *`Constructor.prototype`* for delegation. Usually, the *`super()`* constructor is also called.
- Those steps form **single-ancestor parent/child hierarchies** and **create the tightest coupling available in OO design.**
- **Prototypal Inheritance:** **A prototype is a working object instance.** Objects inherit directly from other objects.
- Classes deal with an idea of an object. Prototypes deal with the objects themselves.
### Problems with class inheritance
> Favor object composition over class inheritance
>
> ~ The Gang of Four, "Design Patterns"
> Using class inheritance in JavaScript is like driving your new Tesla Model S to the dealer and trading it in for a rusted out 1973 Ford Pinto.
>
> ~ Eric Elliot
- Class inheritance causes many well known problems in OO design:
- **The tight coupling problem** (class inheritance is the tightest coupling available in OO design)
- **The fragile base class problem**
- **Inflexible hierarchy problem** (eventually, all evolving hierarchies are wrong for new uses)
- **The duplication by necessity problem** (due to inflexible hierarchies, new use cases are often shoe-horned in by duplicating, rather than adapting existing code)
- **The Gorilla/banana problem**
> *“**…the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. **You wanted a banana but what you got was a gorilla holding the banana** and the entire jungle.”* *~ Joe Armstrong —* “Coders at Work”
## Prototypes
- 3 types of prototypal OO:
- **Concatenative
...