Evitar variables globales....

[Casimiro Noteví]

Yo uso una nomenclatura "propia" derivada de la notación húngara de Charles Simonyi, por ejemplo, para las constantes uso este tipo de nomenclatura:

Código Delphi [-]
const
  _CONFIGINI_  : string = 'config.ini';
  _RUTA_BD_    : string = '\BasesDatos\';

Y para las variables globales, similar, pero en minúsculas:

Código Delphi [-]
public
  _iCodEmpresa_   : integer;
  _dFechaTrabajo_ : TDateTime;

De esa manera siempre tengo controlado cada cosa.

[linuxtin]

Gracias a todos por sus opiniones!!

Delphius toco el tema de acoplamiento y cohesión,como hacen ustedes para lograr una alta cohesión y un bajo acoplamiento en delphi? Como puedo guiarme para saber cuando tengo que descomponer una unidad en varias?

Saludos!

[[Delphius]]

Empezado por Casimiro Notevi

Yo uso una nomenclatura "propia" derivada de la notación húngara de Charles Simonyi, por ejemplo, para las constantes uso este tipo de nomenclatura:

Código Delphi [-]const _CONFIGINI_ : string = 'config.ini'; _RUTA_BD_ : string = '\BasesDatos\';

Y para las variables globales, similar, pero en minúsculas:

Código Delphi [-]public _iCodEmpresa_ : integer; _dFechaTrabajo_ : TDateTime;



De esa manera siempre tengo controlado cada cosa.

¿A cuál publicación de Simonyi te refieres amigo? ¿A la original, o la que terminó publicando Microsoft? Esto te lo pregunto justamente por lo que he leído en este artículo.
Una mala interpretación de las palabras de Charles terminó en lo que se conoció como Notación Húngara que promovió Microsoft.

Empezado por linuxtin

Gracias a todos por sus opiniones!!

Delphius toco el tema de acoplamiento y cohesión,como hacen ustedes para lograr una alta cohesión y un bajo acoplamiento en delphi? Como puedo guiarme para saber cuando tengo que descomponer una unidad en varias?

Saludos!

No hay una receta mágica para eso. Es cosa de análisis, y hay tantas maneras de evaluarlo como personas. Cada quien tendrá su forma de verlo, y sabes ¡puede que todos tengan razón!

Mientras te sientas cómodo con tu diseño, no deberías preocuparte. Es en cuanto dudas en donde debes preocuparte.
Si tu estás siguiendo un proceso basado o apoyado en métricas quizá podrías proponer alguna que represente cualitivamente un aproximado de cuanto acomplamiento y cohesión tienes... si logras tener por decirlo de algún modo 0,5 y 0,5 ¡estás hecho!

Dale una revisada al libro Ingeniería de Software: un enfoque práctico de Robert Pressman. De allí te puedes hacer una idea.

También hay que considerar el hecho de al considerar el paradigma OO ya tenemos dos tipos de Acoplamiento: el acoplamiento entre los módulos o unidades, ¡y el acomplamiento mismo entre las clases!

Saludos,

[Casimiro Noteví]

Empezado por Delphius

¿A cuál publicación de Simonyi te refieres amigo? ¿A la original, o la que terminó publicando Microsoft? Esto te lo pregunto justamente por lo que he leído en este artículo.
Una mala interpretación de las palabras de Charles terminó en lo que se conoció como Notación Húngara que promovió Microsoft.

A la original, ten en cuenta que yo empecé con estas cosas en 1985 , no existía windows y casi, casi... ni microsoft , y básicamente Simonyi lo usaba para el lenguaje C, que al contrario que "nuestro" Delphi, podías (y puedes) asignar valores de un tipo a variables de cualquier otro tipo y, como es natural, te saltaban unos errores tremendos.
Así que yo también usé esa técnica ya por aquella época, por ejemplo:

Código Delphi [-]
var
  iCodInforme,
  iIndice     : integer;
  fPorcentaje : float;
  aiParametros: array of integer;
  dFecha      : TDateTime;
  cCuenta,
  cPrefijo    : string; 
  bAceptado   : boolean;

Como ves, todavía usa el prefijo 'c' para string porque en lenguaje C los strings no existen, son cadenas de 'c'aracteres, y sigo nombrándolos así.
Uso los prefijos para todo, así es muy difícil equivocarse, por ejemplo:

Código Delphi [-]
iDato := 1;
cDato := 'Hola';
fCantidad := 2.36;
aiValor[iX] := 3;      // array de integer

Es casi imposible equivocarse porque estoy viendo el tipo de dato que espera la variable.

Todos los componentes y controles, igual, con 2 caracteres:

Código Delphi [-]
lbAviso : TLabel;
edCliente : TEdit;
cbOpciones : TComboBox;
dtFecha : TDateTimePicker;

Sin embargo para los controles de datos, uso las mayúsculas:

Código Delphi [-]
DScuentas : TDataSource;
TRprincipal : TTransaction;
DBprincipal : TDataBase;

Por eso digo que uso una versión "propia", porque con los años he ido amoldándolo a mis necesidades.

Además de evitar errores también facilita la lectura de código fuente, lo hace más intuitivo a la hora de depurar, por ejemplo.

Hay varias cosas que dice el texto que has enlazado y que estoy de acuerdo:

El Húngaro para Aplicaciones fue algo extremadamente valioso, especialmente en los días de programación C donde el compilador no te daba una muy útil verificación de tipos.

Como he dicho antes, en aquella época era esencial.

Pero hay aun un tremendo valor en el Húngaro para Aplicaciones, en que incrementa el factor de colocación del código, hace que sea fácil de leer, escribir, depurar, y mantener, y, más importante aún, hace que el código defectuoso se vea defectuoso.

Pues eso, lo que he dicho antes, totalmente de acuerdo.

Antes de continuar, hay una cosa más que prometí hacer, la cual es meterme con las excepciones una vez más. La última vez que lo hice me metí en un montón de problemas. En una frase algo fuera de tono en la pagina de “Joel on Software”, escribí que no me gustan las excepciones porque ellas son, verdaderamente, un goto invisible, lo cual, razoné, es aun peor que un goto que puedes ver. Claro está decir que millones de personas se abalanzaron por mi garganta. La única persona en el mundo que salto en mi defensa fue, claro está, Raymond Chen, quien es, de paso, el mejor programador del mundo, así que tiene algo que decir, no?

Tiene toda la razón, muchas veces las excepciones son 'gotos' a no se sabe dónde