Design by contract, implementando primeiro um contrato

Design by Contract é baseado em uma poderosa metáfora de como elementos de um sistema de software de interagir uns com os outros, da mesma forma que as empresas colaboram: com base em obrigações ebenefícios mútuos. 

O "cliente" e "fornecedor" concordar com um "contrato" que:

• O fornecedor deve fornecer um resultado determinado (obrigação) e tem o direito de esperar que o cliente ter satisfeito as condições exigidas (benefício).
• O cliente deve satisfazer estas condições (obrigação) e tem o direito de obter o resultado (benefício).
• Ambas as partes devem cumprir determinadas leis e regulamentos gerais, aplicando-se a todos os contratos.

Design by Contract transforma esses elementos em componentes integrais do software: pré-condições (obrigações do cliente, benefícios fornecedor);

Pós-condições (benefícios de cliente, obrigações do fornecedor);

Invariantes (regras gerais). 

Esses conceitos existem em todos os níveis:

• requisitos
• projeto
• implementação
• teste

Design by Contract revoluciona construção de software por eliminará erros antes que eles têm a oportunidade de prejudicar o software.

Design by Contract fornece:

• documentação automática, de alta qualidade.
• quadro integrado para testes específicos e eficazes.
• a capacidade de comunicar seu projeto sem a necessidade de descrever os detalhes da implementação.
• um guia claro e simples ao longo de todo o processo de desenvolvimento de software.

Aguardar uma certa condição para garantir que uma informação no módulo de clientes o chame: a pré-condição da rotina — uma obrigação para o cliente, e o benefício do fornecedor (a rotina em si), eliminando casos de executar por outros meios.

• Garantir uma certa condição de saída: A pós-condição da rotina — uma obrigação do fornecedor, e obviamente um benefício (o maior benefício de chamar a rotina) para o cliente.
• Manter uma determinada propriedade, assumida na entrada e garantida na saída: uma Classe Constante.

É possível resumir Programação por contrato através de "3 perguntas" que um designer deve-se fazer constantemente:

• O que isto prevê?
• O que isto garante?
• O que isto mantém?

É um desafio para a construção de uma especificação que:

• é o mais simples possível
• é o mais claro possível
• não tem nenhuma ambiguidade
• é totalmente preciso
• permite que o leitor ignore completamente os detalhes de implementação (a menos que há um bug)
• forneça entendimento ao leitor o mais rápido possível, com pouca chance de mal-entendido

 Design By Contract é muito útil para a criação de classes e interfaces. 

Ele pode tanto orientar a descoberta de um design mais robusto.

Referências:

• http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_por_contrato
• http://www.javapractices.com/topic/TopicAction.do?Id=194
• http://c2.com/cgi/wiki?DesignByContract
• https://www.eiffel.com/values/design-by-contract/
• http://en.wikipedia.org/wiki/Design_by_contract

Web Components a new perspective to web development

This new concept it was created jointly by Firefox and Google and promise change some paradigms.

"The component model for the Web called Web Components consists of four pieces designed to be used together to let web application authors define widgets with a level of visual richness not possible with CSS alone, and ease of composition and reuse not possible with script libraries today."

Web Components consist of 4 proposals: 

1. Templates

Templates are parts of DOM that could be reusable, and this Templates will be append to the DOM. That means <img> sources are not downloaded, scripts are not executed until necessary, saving on bandwidth and processing ,and also the script necessary to execute this component in this example querySelector is hidden on the Template to avoid influencing in the other part of the page.

demo: http://jsfiddle.net/warpech/7y6kp/

2.Shadow DOM

Shadow DOM provides encapsulation to markup and style, for example a <video> tag , this tag has many scripts to provide functionality . Each of those controls is implemented as a <div> inside of the <video> tag that is actually not accessible for the scripts on the page but is rendered on users screen.

Shadow DOM is a tool that provide to web developer create own component like tag <video> or <img>.

demo:http://jsfiddle.net/Wnsf6/

3.Custom Elements 

Custom Elements can react to the DOM lifecycle events. That enables them to have a certain behaviour when they are added to DOM, their attributes change or they are removed from DOM.

Is possibility to create own first-class DOM members (fist-class DOM could be considered <div>,<p>,<br> etc ... ).

demo:http://jsfiddle.net/7y6kp/7/

4.Imports 

Imports load external resources, such as Templates or Custom Elements. Imported HTML files can contain templates, stylesheets and scripts. They get executed when the import is loaded.

Why do I care about this? 

• You are a HTM user, this will help you do more advanced this easily.
• You are a front end dev, you want to reuse components across pages.
• You build single pages apps and want a better way to organize things.
• You are interested in the direction that the web platform is heading.

 Unfortunately these components were available just to Google Chrome Canary or for test in jsFiddle.

But is possible use Polymer or Component Kitchen to use web components in another browsers.

Site with discussion and best-practices  http://webcomponents.org

References:

• http://blog.sethladd.com/2012/11/your-first-web-component-with-dart.html
• https://gist.github.com/warpech/9431953 
• http://www.webcomponentsshift.com
• http://pt.slideshare.net/richbradshaw/introduction-to-web-components-38790230
• http://webcomponents.org/presentations/web-components-why-you-are-already-an-expert-at-web-directions/
• http://webcomponents.org/presentations/a-future-called-web-components-at-front-trends/
• http://tableless.com.br/web-components-introducao/
• https://www.youtube.com/watch?v=fqULJBBEVQE

Pattern Backends for Frontends - BFF

There are some functionalities in server side that are necessary to be exposed to mobile and desktop interface What should we do?

Should we create a new operation in the API with more data that we can use in both interfaces?

No, it is not a good idea.

Because of the nature of this interface is different, the experience to mobile user and web user is different.

In mobile interfaces there is less space in screen, so we should expose less data.

Opening lots of connections to server-side resources can drain battery life and limit data plans.

 Therefore, our mobile devices will want to do different calls, less calls, and maybe show different data summarized those desktop devices.

 Another problem is that just one backend API, can become a bottleneck to release new versions, because it can have many changes in the same API to many consumers and to detect possible bugs or errors could be a problem.

 The tendency to API in general is to have multiples responsibilities, so it required much work, and sometimes is necessary creating teams to care this base code.

This can become a problem worse, front-end team and back-end team have to interact with different team to get changes, to expose operations and to consume operations, now there are three different teams to align the same priorities.

Backend for Frontend Pattern definition:

 The application should be returned to user with two different components, one to mobile device other to desktop devices, and should be keeping with specific team, mobile team should keep their API and desktop should keep their API.

If this way is easier adjust to kind of client.

 Release time can be diferent:

It was created to care to several consumers that we have nowadays to the same system, where each one have a requirement.

BFF is focused in a just only user interface, and that it.This allows that to be exclusive consequently will be less.

 When it is delivered the same user experience to different platforms, there are two ways.

it can be utilized with call aggregator to parallelize calls, and it could reduce battery and band to mobile interfaces.

Working with failures on services:

In this example if inventory is down, it is not necessary interrupt the user actions, when service is available again, the users can consult the product inventory that was selected.

BFF reuse:

 The same possibilities in above BFFs diferentes, in this case we can use an aggregator to call the common services

 

Where do we want to go? Evolution of the BFF

We can limit the numbers of consumers according to the  device.

This can work with changes.

Helping development teams to become more focused to his costumer, giving more autonomy to each team.

Each team can control their future, providing specialty for your type of consumer.

Move the system to a less coupled design.

Reference:

http://samnewman.io/patterns/architectural/bff/

https://www.thoughtworks.com/insights/blog/bff-soundcloud

https://www.thoughtworks.com/radar/techniques/bff-backend-for-frontends

My slides: http://www.slideshare.net/salerno1/front-end-architecture