Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit bb31c1d

Browse files
pyjaimeshekhargulati
authored andcommitted
Review translations (#23)
1 parent beebb08 commit bb31c1d

File tree

8 files changed

+201
-154
lines changed

8 files changed

+201
-154
lines changed

‎es/01-default-static-interface-methods.md‎

Lines changed: 11 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,11 @@
11
Métodos Estáticos y por defecto en Interfaces
22
--------
33

4-
Todos entendemos que deberíamos programar con interfaces. Los interfaces dan al cliente un contrato que deberían usar sin preocuparse en los detalles de la implementación (p.e. las clases). Por lo tanto, fomentan **[el bajo acoplamiento](https://en.wikipedia.org/wiki/Loose_coupling)**. Diseñar interfaces limpios es uno de los aspectgos más importantos en el diseño de APIs. Uno de los principios SOLID **[Segregación de interfaces](https://en.wikipedia.org/wiki/Interface_segregation_principle)** habla sobre diseñar interfaces específicos para el cliente más pequeños en vez de un interfaz más genérico. El diseño de interfaces es la clave para tener APIs limpios y efectivos para nuestas librerías y aplicaciones.
4+
Todos entendemos que deberíamos programar con interfaces. Los interfaces dan al cliente un contrato que deberían usar sin preocuparse en los detalles de la implementación (p.e. las clases). Por lo tanto, fomentan **[el bajo acoplamiento](https://en.wikipedia.org/wiki/Loose_coupling)**. Diseñar interfaces limpios es uno de los aspectos más importantes en el diseño de APIs. Uno de los principios SOLID **[Segregación de interfaces](https://en.wikipedia.org/wiki/Interface_segregation_principle)** habla sobre diseñar interfaces específicos para el cliente más pequeños en vez de un interfaz más genérico. El diseño de interfaces es la clave para tener APIs limpios y efectivos para nuestas librerías y aplicaciones.
55

66
> El código de esta sección está en [ch01 package](https://github.com/shekhargulati/java8-the-missing-tutorial/tree/master/code/src/main/java/com/shekhargulati/java8_tutorial/ch01).
77
8-
Si has diseñado algún API, con el tiempo, habrás sentido la necesidad de añadirle nuevos métodos. Una vez que se publica el API se hace imposible añadir métodos a un interfaz sin romper las implementaciones existentes. Para aclarar este punto vamos a suponer que estamos desarrollando un API sencillo de una calculadora `Calculator` que soporta las operaciones de sumar `add`, restar `subtract`, dividir `divide` y multiplicar `multiply`. Podemos escribir el interfaz `Calculator`como se muestra abajo. ***Para hacerlo sencillo usaremos enteros.***
8+
Si has diseñado algún API, con el tiempo, habrás sentido la necesidad de añadirle nuevos métodos. Una vez que se publica el API se hace imposible añadir métodos a un interfaz sin romper las implementaciones existentes. Para aclarar este punto vamos a suponer que estamos desarrollando un API sencillo de una calculadora `Calculator` que soporta las operaciones de sumar `add`, restar `subtract`, dividir `divide` y multiplicar `multiply`. Podemos escribir el interfaz `Calculator`como se muestra debajo. ***Para hacerlo sencillo usaremos enteros.***
99

1010
```java
1111
public interface Calculator {
@@ -20,7 +20,7 @@ public interface Calculator {
2020
}
2121
```
2222

23-
Para respaldar este interfaz `Calculator` desarrollaste la implementación de `BasicCalculator` como se muestra abajo.
23+
Para respaldar este interfaz `Calculator` se desarrolló la implementación de `BasicCalculator` como se muestra abajo.
2424

2525
```java
2626
public class BasicCalculator implements Calculator {
@@ -52,7 +52,7 @@ public class BasicCalculator implements Calculator {
5252

5353
## Métodos de Factoría Estáticos
5454

55-
El API calculadora resultó ser muy útil y fácil de usar. Los usuarios sólo tienen que crear una instancia de `BasicCalculator` y ya pueden usar el API. Comienzas a ver código como el que se muestra abajo.
55+
El API calculadora resultó ser muy útil y fácil de usar. Los usuarios sólo tienen que crear una instancia de `BasicCalculator` y ya pueden usar el API. Basta con usar código como el que se muestra debajo.
5656

5757
```java
5858
Calculator calculator = new BasicCalculator();
@@ -72,7 +72,7 @@ class BasicCalculator implements Calculator {
7272
}
7373
```
7474

75-
Luego, escribiremos una clase factoría que nos facilite la instancia de `Calculator` como se muestra abajo.
75+
Luego, escribiremos una clase factoría que nos facilite la instancia de `Calculator` como se muestra debajo.
7676

7777
```java
7878
public abstract class CalculatorFactory {
@@ -111,7 +111,7 @@ public interface Calculator {
111111

112112
## La Evolución del API con el tiempo
113113

114-
Algunos de los consumidores decidieron o bien, ampliar el API `Calculator` añadiendo métodos como resto `remainder`, o escribit su propia implementación del interfaz `Calculator`. Tras hablar con tus usuarios sacaste la conclusión de que a la mayoría de ellos les gustaría tener un método `remainder` en el interfaz `Calculator`. Parecía un cambio muy simple al API por lo que añadiste un método nuevo.
114+
Algunos de los consumidores decidieron o bien, ampliar el API `Calculator` añadiendo métodos como `remainder`, o escribir su propia implementación del interfaz `Calculator`. Tras hablar con tus usuarios sacaste la conclusión de que a la mayoría de ellos les gustaría tener un método `remainder` en el interfaz `Calculator`. Parecía un cambio muy simple al API por lo que añadiste un método nuevo.
115115

116116
```java
117117
public interface Calculator {
@@ -156,7 +156,9 @@ default int remainder(int number, int divisor) {
156156

157157
## Herencia múltiple
158158

159-
Una clase puede extender sólo una clase pero puede implementar múltiples interfaces. Ahora que es posible tener implementación de métodos en interfaces Java tiene herencia múltiple de comportamiento. Java ya tenía herencia múltiple a nivel de tipo y ahora tambén a nivel de comportamiento. Existen tres reglas de resolución que ayudan a decidir que método será elegido:
159+
Una clase puede extender sólo una clase pero puede implementar múltiples interfaces. Ahora que es posible tener implementación de métodos en interfaces Java conseguimos herencia múltiple de comportamiento. Java ya tenía herencia múltiple a nivel de tipo con las interfaces y ahora también a nivel de comportamiento.
160+
161+
Existen tres reglas de resolución que ayudan a decidir que método será elegido:
160162

161163
**Regla 1: Los métodos declarados en las clases tendrán preferencia sobre los definidos en las interfaces.**
162164

@@ -167,7 +169,7 @@ interface A {
167169
}
168170
}
169171

170-
class App implements A{
172+
class App implements A{
171173

172174
@Override
173175
public void doSth() {
@@ -209,7 +211,7 @@ class App implements C, B, A {
209211

210212
Esto imprimirá `Dentro de C`.
211213

212-
**Regla 3: Sino, la clase tiene que llamar explicitamente a la implementación que desea**
214+
**Regla 3: Si no, la clase tiene que llamar explícitamente a la implementación que desea**
213215

214216
```java
215217
interface A {

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /