Sub-Rotina - Programação

Comumente chamamos as sub-rotinas de “Procedimentos” (procedure) ou “Funções” (function). Podemos entendê-las como um trecho de programa escrito separadamente. Como conseqüência temos um trecho menor de código que executa uma única ação específica, isso facilita o entendimento (interpretação) aumentando, portanto a manutenibilidade do código.

Logo, uma sub-rotina pode ser usada em várias partes do sistema, dessa maneira podemos ter aproveitamento em diversos momentos diferentes de uma determinada ação, com a vantagem de que o gerenciamento da lógica dessa ação estar centralizado. Além de poder ser usada em várias partes do programa, a mesma sub-rotina pode, e deve, ser reaproveitada em outros sistemas ou programas. Em reflexo do reaproveitamento, devemos pensar no acoplamento que isso gera. Por isso, é muito importante estar atento e obstinado em alcançar um alto grau de COESÃO para a sub-rotina que estamos codificando.

Um ponto muito sensível nesta abordagem é que geralmente as variáveis que uma sub-rotina vai usar quase sempre são as variáveis do programa que a chamou. Isso é um grau de acoplamento que devemos evitar a todo custo. Devemos criar nossas sub-rotinas com argumentos. Eles são os parâmetros, através deles a sub-rotina pode receber e retornar valores garantindo uma comunicação entre ela e o mundo externo. Ou seja, o programa que a chamou, com uma baixo grau de acoplamento e um alto grau de COESÃO. Ela deve funcionar como uma caixa preta (Wikipédia).
Parâmetros – São os argumentos da sub-rotina. Seguindo a linha de raciocínio acima, os parâmetros são a comunicação da sub-rotina com os demais módulos que a chamarão em algum momento. Podemos entendê-los como a porta de entrada e a porta de saída da Caixa Preta.
Portanto, uma “function” ou “procedure” (em basic “Sub”), sub-rotinas que são, podem receber um conjunto de dados, que serão processados para um objetivo final. Entretanto, no momento de se declarar a sub-rotina é necessário que o programador defina quais, de que tipo, e quantas serão as entradas e saídas necessárias para que a mesma funcione corretamente. Ou seja, podemos e devemos declarar quem são os parâmetros de entrada, quem são os de saída. Podemos também definir valores default para alguns argumentos.

procedure SetPopupMenu(const Value: TPopupMenu;
   const nAllowCreate: Boolean = False);

implementation

procedure TManagerGridZn.SetPopupMenu(const Value: TPopupMenu;
 const nAllowCreate: Boolean);
begin
 if (FPopupMenu = Value) and (Value <> nil) then Exit;

 (* "nAllowCreate" define se o popup menu será sempre criado.
    Considerando o caso de a mesma instância da classe manipular,
    alternadamente, vários DBGrids que compartilham o mesmo popup menu. *)
 If not Assigned(Value) or (nAllowCreate) then
 begin
   FPopupMenu := TPopupMenu.Create(Self);
   FGrid.PopupMenu := FPopupMenu;
   (* Avisa a classe que o popup menu foi criado *)
   FIsPopupExistent := peInternalCreated;
 end
 else
 begin
   FPopupMenu := Value;
    (* Avisa a classe que o popup menu já existia,
      portanto possui itens. Ele foi associado com esses itens *)
   FIsPopupExistent := peExternalAssociation;
 end;

(* notifica a classe que o popup menu foi desassociado *)
 if FPopupMenu <> nil  then
   FPopupMenu.FreeNotification(Self);
end;

O exemplo acima refere-se a um trecho de código usado nos artigos Construção de Componentes - VI e Construção de Componentes V a sub-rotina em questão trata da construção dinâmica de um Popup menu num DBGrid. Os valores atribuídos ao campo “FIsPopupExistent” é um tipo que criei para controlar se o Grid já possuía um menu Popup ou não.

 
TPopupExistent = (peExternalAssociation, peInternalCreated, peInexistent);

O argumento "nAllowCreate" possui um valor default definido igual a false, veja na linha 02. A Palavra resrvada "const" indica que é um parâmetro de entrada. Ou seja, a presença da palvra reservada "const" inica que "nAllowCreate" é uma porta de entrada da caixa preta. Para definir o parämetro de saída devemos usar a palavra reservada "var" antes do identificador.

Veja mais sobre o assunto em "Modularização em Programação: Coesão X Acoplamento, OO X Estruturação, Portugol X UML - a partir de um algoritmo simples".