#2072 A mi tampoco xDDDD
Había que escribir a un thread de stackoverflow por llegar a los 10 millones de preguntas y te lo daban, sin sorteo. Pero eso ya acabó.
Para los estén interesados. http://objgen.com/json?demo=true
Estoy haciendo unos Tests para un API Rest que estamos desarrollando en mi compañía y necesitaba un builder que me crease JSONs lo más rápido posible sin tener que hardcodear toda la estructura.
De nada 
#2080 Uso Postman (extension para chrome) para hacer los tests. Tiene el modo "Pretty" (solo formatea el texto). No te cierra las llaves al abrirlas con lo cual tienes que saber en todo momento cuando cerrarlas. Si son 2-3 atributos paso, a mano. 
#2081 #2082 Una pena que no esté en GitHub para hacer un Fork, por si algún día ya no está disponible tener una copia
Yo recomiendo Postman 3.0, que te guarda las colecciones en la nube y compartirlas por el equipo va volao.
#2087 Caro. Está la opción de guardar una colección en local.
Para los Java Lovers ♥. Olvídate de crear Getters/Setters. https://projectlombok.org
Lo he usado en varios proyectos y la verdad es que... ♥ de lo mejorcito
#2088 te diría que te olvides de los getters y setters sin mas... sin camuflarlos ni nada, no usarlos.
#2089 ¿entonces cómo interactúas con el objeto?
¿le metes un random() y que vaya haciendo cosas él solo con la semilla?
#2090 random() tiene mas sentido que usar getters y setters xD la encapsulación de un objeto es basicamente mantener datos y comportamiento en una misma clase y raro va a ser que un "comportamiento" de un objeto sea un getter o un setter
un ejemplo muy fácil que dijo umbranoide hace bastante y me gusto, uno rompe la encapsulación y el otro no:
class Pelota {
getX();
setX();
}
class Pelota {
posicion();
mover();
}dejo aquí el post: http://188.165.133.240/foro/dev/feda-dev-480499/38#1128
#1128
#2092 eso para mí es camuflar los getters y los setters
hay que escoger una nomenclatura que te permita "escalar" el comportamiento del objeto, pero sigue siendo get/set en la raíz para mí
#2093 en este ejemplo basico que era para que entendieras por donde van los tiros puede llegar a parecer que es "camuflar" pero lo que haces es encapsular, la orientación a objetos se basa en la encapsulación y la cohesión, no es algo que me haya inventado yo ahora, es lo que se lleva diciendo desde hace años xD
pd: hace relativamente que he abierto los ojos con este tema por lo que tampoco soy nadie para poder hablar
class Foo
{
private $bar;
public function getBar()
{
return $this->bar;
}
public function setBar($bar)
{
$this->bar = $bar;
return $this;
}
}
class Foo
{
private $bar;
public function doHelloWorld()
{
return $this->bar;
}
public function defineHello($bar)
{
$this->bar = $bar;
return $this;
}
}
Que... diferencia... hay?
#2095 diferencia "ninguna" pero si no espacias el código y lo haces mínimamente legible "tampoco hay diferencia".. tu ejemplo es un poco mierda de todas formas, es un poco más agradable a la intuición coger el ejemplo que puso el anterior forero
al final son buenas prácticas simplemente
#2096 Si bueno, está escrito en 45s. Lo que quería decir es, no es que no debas usar getters and setters, no debes exponer la estructura de tu objeto, como dice el otro usuario, vale, ahí estoy de acuerdo, pero al final, es llamarlo de otra forma.
#2095Tunnecino:#2094
class Foo
{
private $bar;
public function getBar()
{
return $this->bar;
}
public function setBar($bar)
{
$this->bar = $bar;return $this;
}
}class Foo
{
private $bar;public function doHelloWorld()
{
return $this->bar;
}public function defineHello($bar)
{
$this->bar = $bar;return $this;
}
}Que... diferencia... hay?
Me da la sensación que más que camuflar es implementar el modelo de negocio en la propia entidad.
No sería mejor algo similar a esto?
Entidad.
package Test.Model;
public class Car {
private String brand;
private String horsePower;
private int seats;
/* getters and setters */
}El modelo de negocio.
package Test.Service;
import Test.Model.Car;
import java.util.ArrayList;
import java.util.List;
public class CarService {
public List<Car> getCars(){
List<Car> cars = new ArrayList<>();
/* here some iterator */
Car car = new Car();
car.setBrand("BlaBlaBla..");
car.setHorsePower("100hp");
car.setSeats(5);
[b]/** Si usas MapStruct te olvidas de tener que usar los SETs **/[/b]
cars.add(car);
/* end iterator */
return cars;
}
}
#2098 es que debería ser la entidad la que sabe que hacer consigo mismo... porque delegar el comportamiento con esos datos a un servicio?
y otra cosa... porque esos setters? porque no usas el constructor?
new Car("Seat", "100hp", 5); y ya esta? y la validación de los dato en el constructor y ya esta... te aseguras que el objeto se crea si todo esta bien si o si, sino no se crea
¿algún sitio que sea algo reciente donde aprender la sintaxis de haskell?
Lo único mínimamente reciente que encuentro son sitios de estos del palo de codeacademy super lentos y super tediosos rollo muy bien, has escrito hola mundo en una String, ahora vamos a ponerlo en una función colegui!!1! y me está entrando ansiedad
normalmente me miro la sintaxis en tutorialspoint, me leo alguna cosa vieja por encima y con eso voy tirando
