Gabriel Schade Cardoso apresenta conceitos de linguagem ubíqua e código expressivo no desenvolvimento de software, utilizando exemplos práticos para destacar como a clareza na comunicação e na modelagem pode impactar positivamenta os projetos. Ele relata uma experiência real onde a falta de entendimento comum sobre terminologias resultou em confusões iniciais, mas foram superadas através do uso eficaz da linguagem ubíqua e ajustes no código. A importância de métodos expressivos e tipagem na programação é enfatizada, mostrando como isso pode evitar erros e otimizar o desenvolvimento.

1. Linguagem Ubíqua +
Código Expressivo =
Felicidade :)
GABRIEL SCHADE CARDOSO

2. Quem é esse tal de Gabriel?

3.  Bacharel em ciência da computação
 Mestre em computação aplicada
 Microsoft Innovative Educator (MIE)
 Microsoft Specialist (MS)
 C#
 Javascript
 ASP .NET MVC
3
GUI
Sobre mim

4.  Microsoft Certified Solutions Assiciate (MCSA)
 Web Applications
 Autor dos livros da editora casa do código sobre
os assuntos:
 Kinect
 Windows Phone
 Programação Funcional
4
GUI
Sobre mim

5.  Desenvolvedor Senior
 Professor
 Revisor
5
GUI
Sobre mim

6. Linguagem Ubíqua

7. Linguagem Ubíqua
 A linguagem ubíqua ou linguagem onipresente é uma
técnica que faz parte do bloco estratégico do DDD.
 Ela nos ajuda na comunicação, contextualização,
identificação e delimitação de conceitos.

8. Linguagem Ubíqua
 De forma muito resumida, linguagem ubíqua é: Todos
falando a mesma língua e usando as mesmas
palavras para definir as mesmas coisas.
 Simples, certo?
 Nem tanto...

9. Linguagem Ubíqua
 Como modelarmos este objeto?
 Bolacha?
 Biscoito?
 Não importa!
Desde que...

10. Uma triste história real :(

11. Uma triste história real
 Início do projeto atual que trabalho;
 O time do qual faço parte é responsável por
desenvolver um sistema de locação de automóveis de
uma empresa de Minas Gerais.

12. Uma triste história real
 Quatro membros do time são de São Paulo e dois de
Itajaí;
 Fizemos uma reunião de kick-off e recebemos a
documentação com os requisitos do cliente.

13. Uma triste história real
 Não tínhamos um grande conhecimento sobre o
projeto;
 Mapeamos as histórias de usuário, enviamos para o
cliente e começamos a desenvolver.

14. Uma triste história real
 Em vários momentos da documentação citavam:
carros, veículos e modelos... Mas afinal o que era o
que?

15. Uma triste história real
 Fiat Uno é um...
 Modelo?
 Veículo?
 Carro?

16. Uma triste história real
 Fiat Uno é um...
 Modelo?
 Veículo?
 Carro?

17. Uma triste história real
 Fiat Uno é um...
 Modelo?
 Veículo?
 Carro?

18. Uma triste história real
 Após conversas, concluímos
que:
 Um veículo Uno da marca
Fiat possui os modelos:
vivace, celebration, way, etc

19. Uma triste história real
 Depois de um pouco de sofrimento e deste
entendimento (que nem o cliente tinha) falamos
abertamente na reunião sobre linguagem ubíqua.

20. Uma triste história real
 Tudo correu bem, até que...
 Descobrimos que os três agrupamentos de
modelos eram a mesma coisa, mas o cliente
usava nomes diferentes

21. Uma triste história real
 Classes;
 Grupos;
 Categorias.

22. Uma triste história real
 A documentação inclusive exemplificava com
valores diferentes!

23. Uma triste história real
 Paramos a Sprint e
fizemos a maior call do
projeto com essa cara 

24. Uma triste história com um final feliz
 Depois desta call remodelamos diversas coisas
no sistema, mandamos uma nova proposta para
o cliente e tudo começou a correr bem.

25. Uma triste história com um final feliz
 Para a linguagem ubíqua ser mais eficaz nosso
código também precisa refletir as coisas que
conversamos, precisamos de um código
expressivo.

26. Código Expressivo!

27. Código expressivo
 Existem diversas definições para código
expressivo.
“O código precisa expressar a linguagem mais
humana possível”

28. Código expressivo
 Se um veículo tem uma descrição, o tipo/classe
que o representa, precisa ter uma propriedade
chamada descrição e não título ou nome.

29. Código expressivo
 Este é o nível mais básico de expressividade,
podemos ir muito além e alcançar o nível bem
mais avançado.

30. Modelando o domínio!

31. Código expressivo
 Vamos para um exemplo em outro domínio mais
simples: um jogo de baralho, como pife, por
exemplo.

32. Código expressivo
 Sabemos que uma partida de baralho possui os
seguintes elementos:
 Cartas
 Baralho
 Jogadores

33. Código expressivo
 Cartas são compostas por uma combinação de
valor + naipe...
 Quais são os valores possíveis?
 Quais são os naipes possíveis?

34. Código expressivo

35. Código expressivo
 E o resto?

36. Código expressivo
 Tudo certo!
 Será mesmo?

37. Código expressivo

38. Código expressivo
 Após a implementação deste domínio
precisamos implementar o comportamento de
comprar uma carta.

39. Código expressivo
 Esta modelagem, não impede isso...

40. Código expressivo
 Sugestões de solução?
 Passar a partida por parâmetro?
 Criar um classe para baralho e outra para a mão?

41. Tipagem com alias e F#!

42. Tipagem
 O paradigma funcional reforça bastante o uso
de tipos ao invés de classes.
 Vamos para a mesma modelagem!

43. Tipagem

44. Tipagem
Não são enums!

45. Tipagem
Produto escalar
de tipos!

46. Tipagem
Guardam valores do
Mesmo tipo, mas
Possuem nomes
diferentes

47. Tipagem

48. Tipagem
 Escreve-se menos código e conseguimos
modelar de forma melhor...
 Veja o mesmo exemplo do método de comprar
cartas:

49. Tipagem
 Esta modelagem, impede:

50. Código expressivo

51. Métodos também são
gente!

52. Métodos
 Outro ponto importante do código expressivo é
a criação correta de métodos e a extensibilidade
de comportamentos.

53. Métodos
 O C#, Java e diversas outras linguagens já
incorporaram alguns conceitos funcionais, entre
eles, tornar os métodos membros de primeira
ordem.

54. Métodos
 Ou seja, eles podem ser passados por
parâmetro, retornados e até se comportarem
parecidos com objetos.
 São os chamados delegates.

55. Métodos
 A principal vantagem é termos mais segurança
no código evitando funções mentirosas.

56. Métodos
 Para exemplificar vamos utilizar um código
bastante simples e inseguro:
 Tenha como premissa que há na mão de um jogador
as cartas:
 Ás de copas
 Ás de ouros
 Dama de espadas

57. Métodos
 O que irá acontecer se realizarmos esta
operação?

58. Métodos
 Estamos tentando obter a primeira carta cujo
naipe seja paus;
 Conforme dito anteriormente, não há nenhuma
carta deste naipe...

59. Métodos
 O método FirstOrDefault do LINQ retornará o
valor padrão (default) do tipo Carta.
 Isso fará com que qualquer tentativa de acesso
à uma propriedade ou método cause problemas

60. Métodos
 Porque cartaPaus é um valor nulo e este tipo apenas se
disfarça de outros valores, ele não é um valor real de carta.

61. Métodos
 Como resolver?
 Vamos criar nossa própria busca!

62. Métodos
 Nossa busca precisa retornar um objeto que pode ou não
conter uma carta, mas que faça isso de maneira segura, ao
invés do nulo.
 Quando um objeto pode ou não ser retornado é comum ele ser
chamado de valor opcional dentro do paradigma funcional.

63. Métodos
 Uma outra nomenclatura bastante utilizada é o Maybe, ou em
português, Talvez.
 Então precisamos criar uma busca que talvez retorne uma
carta.

64. Métodos
 Este tipo de implementação geralmente é um pouco mais
avançada, mas não se assuste, faremos um passo-a-passo!
 A primeira coisa é criarmos a classe para representar este
dado incerto.

65. Métodos

66. Métodos
 Esta implementação atende este caso, mas é melhor deixá-la
mais genérica.

67. Métodos
 Precisamos agora, criar nossa lógica para encapsular o valor
de forma fluída e simples de usar.

68. Métodos

69. Métodos
 Vamos fazer nossa consulta para que ela talvez retorne uma
carta.

70. Métodos

71. Métodos
 Agora podemos usar desta forma:

72. Métodos
 Mas e se o programador simplesmente acessar a propriedade
Valor e ela estiver nula?

73. Métodos
 Este código está bom?
 Não...
 Ainda não resolvemos nenhum problema, mas calma, vamos
chegar lá.

74. Métodos
 Primeiro vamos ajustar todas besteiras feitas na classe
consultas, um total de DEZ erros.

75. Métodos

76. Métodos
1. Esta classe deveria ser estática, ela não guarda estado e é
somente uma extensão;
2. O método TentarObter também deveria ser estático
3. Deveria ser possível retornar qualquer tipo de valor
4. Deixaremos este erro para depois;
5. Deveria ser possível a consulta em qualquer tipo de coleção
6. A coleção deveria ter um nome mais genérico que “cartas”

77. Métodos

78. Métodos
7. A consulta está sendo feita de forma FIXA;
 Como resolver isso?
 Precisamos passar o método da consulta por parâmetro!

79. Métodos

80. Métodos
 Os últimos 3 problemas restantes se referem à consulta estar
contendo a lógica para a criação de um objeto do tipo Talvez.
 Vamos resolver isso alterando a classe Talvez!

81. Métodos

82. Métodos
 Estamos quase lá...
 Veja como o código está ficando melhor:

83. Métodos

84. Métodos
 Vamos para o toque final, já notamos que deixar a propriedade
Valor acessível é uma ideia ruim, pois pode gerar problemas
com null, então vamos restringir o acesso a ela.

85. Métodos
 Agora precisamos fazer com que o programador só consiga
utilizar ela quando existir um valor:

86. Métodos
 E como utilizamos?

87. Métodos
 Já chegamos em um resultado muito bom, criando uma
estrutura nova com o Obter da classe Talvez, mas ainda há
alguns pequenos refinamentos no código.
1. Transformar a função TentarObter em uma extensão do LINQ
2. Facilitar a criação de objetos do tipo Talvez

88. Métodos
 Para fazermos o TentarObter se tornar uma extensão como o
LINQ, basta tornar este método um extension method.

89. Métodos

90. Métodos
 Para facilitar a criação de objetos do tipo Talvez precisamos
criar um cast implícito.
 Sobrecarregando o operador de cast permite a conversão
implícita, como já ocorre do int para o double, por exemplo.

91. Métodos
 Com esta facilidade não precisamos mais criar o objeto Talvez
na consulta, podemos simplesmente declarar que retornamos
ele e o C# faz a magia acontecer.

92. Métodos

93. Métodos

94. Métodos

95. Métodos
 O legal disso, é que agora temos extensão para utilizar em
todas as coleções do projeto, veja outro exemplo:

96. Métodos
 Ainda existe um problema inerente à nossa classe Talvez;
 Ela ainda é uma classse...
 Então ela pode ser nula!
 Como resolver?
 Utilize struct ao invés de classe

97. Métodos
 Existem muitas outras funcionalidades que poderíamos
conversar, mas por hoje é só.

98. Me encontre em
/gabrielschade
/gabrielschade
/gabrielschade
/gabrielschade
https://gabrielschade.github.io

99. Perguntas?