Após as turbulências voltamos ao normal, ou quase. O número de visitas caiu pela metade neste período, então por favor avisem a seus amigos que o blog mudou: philcalcado.com. As URIs antigas devem funcionar mas esta é a oficial.
Nestes últimos dias acabei migrando para o Gnome. Eu nunca fui muito com a cara do gerenciador, mas acho que sempre foi por birra minha com o Miguel de Icaza. Eu nunca engoli direito a história de se implementar as pseudo-especificações da Microsoft como Software Livre em vez de investir em uma plataforma como Java, Python, Ruby ou Strongtalk, mas enfim, hoje em dia eu até Mono uso…
O Gnome segue um paradigma mais minimalista, quem está acostumado com muitas opções sofre um pouco mas anda fácil depois de um tempo. Eu não diria que é melhor ou pior que o KDE< é questão de costume e gosto apenas. O problema que eu venho experimentando não está no Gnome ou KDE e sim nos softwares que os acompanham. Para a maioria das pessoas que usam um computador as configurações de fábrica são mais que suficientes. para um programador este não é o caso. Nós sempre temos que experimentar,t estar e acabar com um HD torrado ou algo parecido. No caso destes ambientes, "algo parecido" geralmente é uma aplicação travando. O problema acontece mais frequentemente com aplicações pequenas, aquelas que ficam nas respectivas docks. É interessante que na maioria dos casos as aplicações funcionam normalmente, mas basta quebrar uma dependência, tentar algo muito diferente e elas desabam. Aí você procura uma solução na internet e descobre que aquele comportamento se deve ao fato da aplicação fazer várias suposições sobre o ambiente que roda, por exemplo que está no KDE ou Gnome. E falha.
Vivi um caso parecido há poucas horas. Era uma página de Internet simples, o problema consistia apenas em XHTML e JavaScript. Uma determinada <div> continha uma objeto flash dentro de si e em alguns casos especiais ele deveria ser substituído por outro. Aí entra o problema. O objeto original faz parte de um determinado framework de anúncios, o novo faz parte de outro. Ao trocar o conteúdo havia um problema de JavaScript que só se manifestava no pior browser: Internet Explorer 6.0. Este browser possui recursos pífios de depuração e por anos é a dor-de-cabeça do pessoal de implementação client-side. Eventualmente, após muitos alert()s, descobrimos que o problema era que o framework original estava no time dos que fazem diversas suposições sobre o ambiente. Ele supunha que existiria um objeto com determinado nome, que uma determinada função estaria disponível, etc. etc. etc.
Estes são dois exemplos simples que mostram o quanto encapsulamento é importante. Você não precisa de objetos para ter encapsulamento (apesar de que se você tem objetos deveria ter encapsulamento), você pdoe encapsular algo como o que sua aplicação expõe e espera encontrar do lado de fora ou como seu JavaScript reage a mudanças na página - Web 2.0, meus caros, Web 2.0 -, o que importa é que seu código abstraia a implementação do que acontece no exterior (uma <div> é uma <div>, não importa se dentro possui o objeto A ou B), qual a implementação das coisas (KDE e Gnome fazem basicamente a mesma coisa) e, principalmente, colabore com as outras aplicações escondendo delas os detalhes da sua implementação.
A “culpa” da quebra de encapsulamento geralmente não está na classe que usa outra e sim na que não oculta dos seus clientes os seus segredos mais íntimos: como diabos ela é implementada.
Belo artigo, parábens !!!
Além de encapsular,,, é necessário também abstrair.
http://archsofty.blogspot.com/2007/06/abstrair-preciso.html