Java Magazine 98

Lista de artigos desta edição:

Novidades do Java 7 no NetBeans 7
Serialização e deserialização em Java – Parte 1
VRaptor 3 – Parte 4
Seam 3: Forge, Solder e Catch
Dojo Toolkit na prática
Padrões de projeto, aprecie com moderação
BDD em aplicações Web
Comunicação AJAX Cross-Domain – Parte 2

O que vou apresentar neste post é uma alternativa simples ao uso de variáveis globais. Esta alternativa consiste em declarar como variáveis locais em um arquivo C, as variáveis que seriam globais. Veja o código a seguir:

/*
* data_access.c
*/
static int data1 = 0;
static int data2 = 0;

int getData1(){
return data1;
}

void setData1(int d1){
data1 = d1;
}

int getData2(){
return data2;
}

void setData2(int d2){
data2 = d2;
}

Através do static limitamos o acesso às variáveis apenas para as funções do arquivo no qual as variáveis foram declaradas. Depois criamos funções para acessá-las (get e set) e deixamos o protótipo dessas funções em um arquivo header (.h). Veja na sequência o arquivo header:

/*
* data_access.h
*/

#ifndef DATA_ACCESS_H_
#define DATA_ACCESS_H_

int getData1();
void setData1(int d1);

int getData2();
void setData2(int d2);

#endif /* DATA_ACCESS_H_ */

E então, incluímos este .h em todos os nossos módulos que vão acessar as variáveis. Este acesso às variáveis é feito através das funções get e set que criamos e não diretamente, pois as variáveis não são visíveis fora do módulo C que criamos. Veja um exemplo de código acessando as variáveis:

#include <stdio.h>
#include "data_access.h"

int main (void){
printf("data 1: %d\n", getData1());
setData2(5);
printf("data 2: %d\n", getData2());
return 0;
}

Fazendo o acesso através de funções temos muito mais segurança no nosso código, pois podemos controlar os momentos em que estas variáveis são acessadas e limitar para que as funções de acesso somente sejam visíveis nos módulos que efetivamente precisem. Usando variáveis globais qualquer parte do programa pode acessar e alterar as variáveis sem termos nenhum controle sobre isso.

Como os usuários enxergam o programador

The Trooper Lego Version

Aqui vai a imagem original:

The Trooper

Java Magazine 96

Lista de artigos desta edição:

jQuery UI na prática
Além da IDE – Parte 4
VRaptor 3 – Parte 3
Inversão de Controle – Parte 2
Dissecando a Java Collections
Nem parece Web: é Vaadin!
Acessibilidade em Java
A importância dos Padrões de Projeto

Super Scorpion World

Muito legal!

Java Magazine 95

Lista de artigos desta edição:

Distribuição de Dados com Java
Java 7 – Aperfeiçoando o Java
Jython
JSF com Prevayler
Spring Security 3, JSF 2 e JPA 2
Seam 3: complementando a lógica com Weld
Inversão de Controle – Parte 1
Nem parece Web: é Vaadin! – Parte 1 (Exclusivo)

import this

A tradução do texto é apresentada a serguir:

O Zen do Python, por Tim Peters

Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Linear é melhor do que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para quebrar as regras.
Ainda que praticidade vença a pureza.
Erros nunca devem passar silenciosamente.
A menos que sejam explicitamente silenciados.
Diante da ambigüidade, recuse a tentação de adivinhar.
Deveria haver um — e preferencialmente só um — modo óbvio para fazer algo.
Embora esse modo possa não ser óbvio a princípio a menos que você seja holandês.
Agora é melhor que nunca.
Embora nunca freqüentemente seja melhor que *já*.
Se a implementação é difícil de explicar, é uma má idéia.
Se a implementação é fácil de explicar, pode ser uma boa idéia.
Namespaces são uma grande idéia — vamos ter mais dessas!