DEV Community: saudade de liberdade

Orientação a Objetos e Biologia??

saudade de liberdade — Wed, 07 Apr 2021 18:02:04 +0000

Nos dias 08, 09 e 10 de junho ajudei a organizar um evento de tecnologia em Brasília, o Brasília Dev Festival e no dia 08, sexta-feira fizemos um workshop sobre C# com a Thamirys Gameiro. Enquanto a Thamirys recordava os conceitos de Orientação a Objetos (O.O.) treinávamos esses conceitos modelando animais como nossos objetos.

Desse exercício, surgiu uma discussão interessante, sobre a qual eu resolvi escrever.

Estudar linguagens de programação modernas cedo ou tarde (e eu diria cedo) nos põe em contato com o conceito de Orientação a Objetos e esse conceito normalmente não é tão facilmente assimilado, principalmente para aqueles que vem do paradigma procedural. A ideia de algo independente com características e comportamentos próprios pode até ser de fácil compreensão mas o problema normalmente surge quando tentamos atravessar o âmbito dos exemplos naturais, para os não naturais, ou seja aqueles que normalmente utilizamos no nosso dia-a-dia de trabalho com programação.

Mas você sabia que tem um motivo particular que explique porque os exemplos naturais fazem tanto sentido para explicar o conceito de O.O.? Existe sim e a razão é que o conceito surgiu da Biologia!

Há alguns anos, Alan kay, um dos pais do paradigma da orientação a objetos, sugeriu uma abordagem de desenvolvimento de software baseado no funcionamento de organismos vivos, essa foi a chamada “analogia biológica”. Kay acreditava que, assim como, um organismo vivo consegue se organizar de forma a resolver problemas, um sistema de software também deveria ser capaz.

Seres vivos são compostos por células, cada célula é independente e autônoma, no entanto elas se unem e trabalham em equipe, através de trocas de mensagens em prol de um objetivo comum.

Gostou da semelhança? Faz sentido então pensar que os sistemas trabalhassem de forma análoga a organismos vivos, e assim surgiu o paradigma de orientação a objetos. Um sistema de software, para o paradigma, é visto como uma coleção de agentes autônomos, chamados de objetos. Esses objetos trabalham em conjunto para realizar tarefas comuns.
Enquanto modelávamos nosso pato no workshop de C# descobrimos que esse pato pertence a uma classe, que ele herda características do pai e que pode assumir comportamentos que normalmente não atribuímos de primeira a uma ave, como nadar, por exemplo.

Já fez a ligação aí né?! Mas vamos fazer um apanhado sobre cada um deles, do meu jeito!

Classes

Classes são agrupadores, tudo aquilo que tem características e comportamentos em comum pertencem a mesma classe. Nosso indivíduo pato, com suas asas, “pés de borracha”, penas e bico, que faz quá-quá e se locomove nadando, andando e voando tem outros semelhantes a ele, ou seja, pertence a um grupo, a classe pato. Fica claro aqui também, que o indivíduo nesse caso, é o objeto, o representante desse grupo que chamamos de classe.

Herança

Esse é na minha opinião o mais simples, a herança é o conceito que liga dois objetos de maneira hierárquica, ou parental, como preferir. A questão é, uma classe mãe ou super-classe, tem classes filhas ou subclasses. De maneira prática classes vão derivar de outras, herdando características e comportamentos. Nosso patinho deriva da classe animal e herda características comuns aos animais, é vivo, se locomove, se alimenta.

Polimorfismo

O polimorfismo, acontece quando em uma classe base há uma assinatura de um método que é propagado para as suas classes derivadas, no entanto, a lógica que está no método da classe base pode mudar para a mesma assinatura nas classes derivadas. Difícil? Nãããão! É mais simples do que parece, o pulo da gato é o seguinte, o carinha tem um método na classe mãe, o método emitirSom() na classe Animal. Nosso patinho então vai sobreescrever esse método emitirSom() aplicando suas próprias características, retornando “quá quá” por exemplo.

Faltaram as classes abstratas e as interfaces que vamos deixar para a segunda parte. E dá próxima vez que precisar modelar/implementar um sistema O.O, você já sabe a quem agradecer ou xingar. kkkk… Viva Alan Kay e a analogia biológica!

Ps.: Trazendo o artigo escrito em 19 de junho de 2018 de outra plataforma para o dev.to

Consumindo apis externas com spring webflux

saudade de liberdade — Thu, 06 Aug 2020 23:10:56 +0000

Há algum tempo ajudando uma amiga com um teste para um processo seletivo, me deparei com o desafio de consumir apis externas. Desafio dado, porque não buscar algo novo e aprender algo diferente? Foi assim que escolhemos o webclient do Spring Webflux para a tarefa.

Segundo a documentação do Spring, o Webflux é a stack reativa do Spring que foi adicionado a partir da versão 5 do framework que está presente na versão 2.0 ou superiores do Springboot. Com ele é possível fazer chamadas síncronas e assíncronas e tem sido utilizado em muitos projetos no mercado, inclusive no que eu trabalho atualmente! :)

Neste projeto vamos consumir apis do star wars a ideia é criar uma api de leilão para os veículos da franquia. Num primeiro momento vamos acessar os endpoints que retornam todos os veículos e os que devolvem os veículos individualmente.
Partiu?

Vamos começar entendendo como disponibilizar essa ferramenta na nossa api. Eu prefiro utilizar o gradle como ferramenta de build e ele foi o escolhido para esse projeto, outro ponto importante, foi que utilizei o spring initializr para criar o projeto, sendo assim foi preciso apenas adicionar a dependência do Spring Reactive Web. Caso prefira criar o projeto de outra maneira, pode adicionar a seguinte linha:
implementation 'org.springframework.boot:spring-boot-starter-webflux'
ao arquivo build.gradle.

Com o webflux disponível, podemos criar nosso webclient que é quem vai orquestrar as nossas requisições a star wars api. Como se trata de uma biblioteca externa precisamos que o Spring possa tomar conta do seu ciclo de vida pra nós, e para isso a transformamos em um bean. Isso pode ser feito na classe que está anotada com o @SpringBootApplication como abaixo:

@SpringBootApplication
public class MyApplication {
  @Bean
  public WebClient webClient(WebClient.Builder builder) {
     return builder.baseUrl("https://swapi.dev/api/")
           .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
           .build();
  }
  public static void main(String[] args) {
     SpringApplication.run(MyApplication.class, args);
  }

}

Ou ainda criar uma classe de onde possamos configurar todos os beans da nossa aplicação, mantendo assim a classe com uma única responsabilidade, o que eu prefiro fazer. A minha ficou assim:

@Configuration
public class BeanConfiguration {

   private String starWarsUrl;

   public BeanConfiguration(StarWarsConfiguration starWarsConfiguration){
       this.starWarsUrl = starWarsConfiguration.starWarsBaseUrl;
   }

   @Bean
   public WebClient webClient(WebClient.Builder builder) {
       return builder.baseUrl(starWarsUrl)
               .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
               .build();
   }
}

Outra boa prática que gosto de seguir, é não manter informações que são dinâmicas 'chumbadas' no código, como é o caso da url base da api que queremos acessar. Para manter essas informações isoladas em um único local preferi guardar os dados no application.properties do meu projeto:

starwars.base-url = https://swapi.dev/api/
starwars.vehicles = vehicles/
starwars.vehicle = vehicles/{id}/

E para acessar esses dados, usei mais uma classe de configuração. Aqui, a única função dela é disponibilizar as informações do application.properties em variáveis.

@Configuration
@PropertySource("classpath:application.properties")
public class StarWarsConfiguration {

   @Value("${starwars.base-url}")
   public String starWarsBaseUrl;

   @Value("${starwars.vehicles}")
   public String starWarsVehicles;

   @Value("${starwars.vehicle}")
   public String starWarsVehicle;
}

Com todas as classes de configurações apresentadas, deixo uma imagem para que fique um pouco mais claro como elas se conversam.

Partindo para as nossas requisições, a ideia foi criar um component cuja função seja apenas isso, acessar a api do star wars e retornar as informações que precisamos. Primeiro, disponibilizo através do construtor o bean do webclient para utilizar nas chamadas e as variáveis que contem as urls que serão buscadas.

@Component
public class StarWarsWebClient {

   private final String allVehiclesResource;
   private final String vehicleResource;
   private WebClient webClient;

   StarWarsWebClient(WebClient webClient, StarWarsConfiguration starWarsConfiguration) {
       this.webClient = webClient;
       this.allVehiclesResource = starWarsConfiguration.starWarsVehicles;
       this.vehicleResource = starWarsConfiguration.starWarsVehicle;
   }

Feito isso é só criar o método que efetivamente vai fazer a requisição. Neste caso buscaremos primeiro todos os veículos e aqui é preciso fazer uma ressalva, se a api externa retornasse apenas uma lista com todos veículos disponíveis [{},{}], poderíamos utilizar um flux e o método ficaria mais ou menos assim:

public Flux<VehicleResponse> getAllVehicles() {
        Flux<VehicleResponse> response = webClient
.get() // metodo http utilizado na requisicao
                .uri(allVehiclesResource) //recurso a ser atingido encapsulado na variavel
                .retrieve() //executa a chamada
                .bodyToFlux(VehicleResponse.class); //transforma a resposta em um Flux do tipo VehicleResponse
        return response;
    }

No entanto a nossa api retorna um único objeto contendo em uma de suas propriedades uma lista de veículos {[]}, nesse caso o método utilizado foi o método a seguir, e por enquanto focaremos só no Mono:

public AllVehicleResponse getAllVehicles() {
   return webClient
           .get()
           .uri(allVehiclesResource)
           .retrieve()
           .bodyToMono(AllVehicleResponse.class)
           .block();
}

E para atingir os veículos individualmente, o processo é quase o mesmo:

public VehicleResponse getVehicle(Integer id) {
   return webClient
           .method(HttpMethod.GET)
           .uri(vehicleResource, id)
           .retrieve()
           .bodyToMono(VehicleResponse.class)
           .block();
}

A diferença está na chamada da uri, a variável vehicleResource contem o recurso seguido do id que está sendo buscado vehicles/{id}/ e na frente dele, uma variável que de fato armazena esse id.

A partir daí qualquer classe service no nosso projeto pode acessar os caras que fazem essas requisições e trabalhar com seus dados. Como no exemplo abaixo:

@Service
public class VehiclesService {
   private final VehicleRepository vehicleRepository;
   private final StarWarsWebClient starWarsWebClient;

   public VehiclesService(VehicleRepository vehicleRepository, StarWarsWebClient starWarsWebClient) {
       this.vehicleRepository = vehicleRepository;
       this.starWarsWebClient = starWarsWebClient;
   }

   public AllVehicleResponse getVehicles() {
       return starWarsWebClient.getAllVehicles();
   }

   public VehicleResponse getVehicle(Integer id) {
       return starWarsWebClient.getVehicle(id);
   }
}

Fácil né? Nos próximos capítulos vamos explorar mais esses dados e montar nossa api de leilões! Quer ver o projeto no git? O link é esse aqui. Espero que tenham gostado.
Até!