-
Notifications
You must be signed in to change notification settings - Fork 0
/
book-Z-H-19.html
50 lines (33 loc) · 4.87 KB
/
book-Z-H-19.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ops="http://www.idpf.org/2007/ops">
<!-- Generated from TeX source by tex2page, v 4o,
(c) Dorai Sitaram, http://www.cs.rice.edu/~dorai/tex2page -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<meta http-equiv="Content-Type: text/html; charset=utf-8"/>
<title>Estrutura e Interpretação de Programas de Computador</title>
<link rel="stylesheet" type="text/css" href="book-Z-C.css" title="default"/>
</head>
<body>
<a name="%_chap_3" id="%_chap_3"/>
<h1 class="chapter">
<div class="chapterheading"><a href="book-Z-H-4.html#%_toc_%_chap_3">Capítulo 3</a></div></h1><p>
<a href="book-Z-H-4.html#%_toc_%_chap_3">Modularidade, Objetos e Estado</a></p><p>
</p><p>
</p><p>
</p><div align="right">
<table width="60%"><tr><td>
<span class="epigraph">
<p>
M<img src="images/ch3-Z-G-1.gif" border="0"/></p><p>
</p><p/><p/><p>(Mesmo que isso mude, ele fica parado).</p><p>
<a name="%_idx_2820" id="%_idx_2820"/>Heráclito</p><p>
Plus ça change, plus c'est la même chose.</p><p>
<a name="%_idx_2822" id="%_idx_2822"/>Alphonse Karr</p><p>
</p></span>
</td></tr></table></div>
<p/><p>Os capítulos anteriores introduziram os elementos básicos a partir dos quais os programas são feitos. Vimos como procedimentos primitivos e dados primitivos são combinados para construir entidades compostas e aprendemos que a abstração é vital para nos ajudar a lidar com a complexidade de grandes sistemas. Mas essas ferramentas não são suficientes para projetar programas. A síntese eficaz do programa também requer princípios organizacionais que podem nos guiar na formulação do projeto geral de um programa. Em particular, precisamos de estratégias para nos ajudar a estruturar grandes sistemas, para que sejam <em>modulares</em>, ou seja, para que possam ser divididos “naturalmente” em partes coerentes que podem ser desenvolvidas e mantidas separadamente.</p><p>
<a name="%_idx_2824" id="%_idx_2824"/><a name="%_idx_2826" id="%_idx_2826"/>Uma poderosa estratégia de projeto, que é particularmente apropriada para a construção de programas para modelagem de sistemas físicos, é basear a estrutura de nossos programas na estrutura do sistema que é modelado. Para cada objeto no sistema, construímos um objeto computacional correspondente. Para cada ação do sistema, definimos uma operação simbólica em nosso modelo computacional. Nossa esperança ao usar essa estratégia é que estender o modelo para acomodar novos objetos ou novas ações não exigirá mudanças estratégicas no programa, apenas a adição dos novos análogos simbólicos desses objetos ou ações. Se formos bem-sucedidos em nossa organização do sistema, para adicionar um novo recurso ou depurar um antigo, teremos que trabalhar apenas em uma parte localizada do sistema.</p><p>Em grande parte, portanto, a maneira como organizamos um grande programa é ditada pela nossa percepção do sistema a ser modelado. Neste capítulo, investigaremos duas importantes estratégias organizacionais decorrentes de duas “visões de mundo” bastante diferentes da estrutura dos sistemas. A primeira estratégia organizacional concentra-se em <a name="%_idx_2828" id="%_idx_2828"/><em>objetos</em>, visualizando um sistema grande como uma coleção de objetos distintos cujos comportamentos podem mudar ao longo do tempo. Uma estratégia organizacional alternativa concentra-se nos <a name="%_idx_2830" id="%_idx_2830"/><em>fluxos</em> de informações que fluem no sistema, da mesma forma que um engenheiro elétrico vê um sistema de processamento de sinais.</p><p>Tanto a abordagem baseada em objetos quanto a abordagem de processamento de fluxo levantam questões linguísticas significativas na programação. Com os objetos, devemos nos preocupar com a forma como um objeto computacional pode mudar e ainda assim manter sua identidade. Isso nos forçará a abandonar nosso antigo modelo de computação de substituição (seção <a href="book-Z-H-10.html#%_sec_1.1.5">1.1.5</a>) em favor de um <a name="%_idx_2832" id="%_idx_2832"/><em>modelo de ambiente</em> de computação mais mecanicista, mas menos teoricamente tratável. As dificuldades de lidar com objetos, mudanças e identidade são uma consequência fundamental da necessidade de lidar com o tempo em nossos modelos computacionais. Essas dificuldades se tornam ainda maiores quando permitimos a possibilidade de execução concorrente de programas. A abordagem de fluxo pode ser totalmente explorada quando dissociamos o tempo simulado em nosso modelo da ordem dos eventos que ocorrem no computador durante a avaliação. Conseguiremos isso usando uma técnica conhecida como <a name="%_idx_2834" id="%_idx_2834"/><em>avaliação atrasada</em>.</p><p>
</p></body>
</html>