PDF de programación - Instrucciones de diseño para programadores de bibliotecas de clases

(cid:1)

(cid:1)

(cid:1)

(cid:2)(cid:1)


Instrucciones de diseño para programadores de
bibliotecas de clases

El entorno administrado de .NET Framework permite a los programadores mejorar el modelo de
programación para hacerlo compatible con una amplia gama de funcionalidades. Las instrucciones
de diseño de .NET Framework tienen como finalidad fomentar la coherencia y la previsibilidad en las
API públicas al habilitar la integración entre lenguajes y el Web. Es muy importante seguir estas
instrucciones de diseño cuando se programan las clases y los componentes que extienden .NET
Framework. El diseño incoherente influye de un modo desfavorable en la productividad de los
programadores. Los complementos y las herramientas de desarrollo pueden convertir algunas de
estas instrucciones en reglas preceptivas de hecho y reducir el valor de los componentes que no las
cumplen. Los componentes que no se ajustan a estas instrucciones de diseño funcionarán, aunque
no lo harán con todo su potencial.

Con estas instrucciones se pretende ayudar a los diseñadores de bibliotecas de clases a
comprender las ventajas y las desventajas entre las distintas soluciones. Puede que haya
situaciones en las que un buen diseño de bibliotecas requiera saltarse estas instrucciones de
diseño. Estos casos no son lo habitual y es importante que una decisión de este tipo esté
adecuadamente justificada. En esta sección se proporcionan instrucciones de uso y de
nomenclatura para los tipos de .NET Framework, así como instrucciones de implementación de
modelos de diseño comunes.



(cid:1)

(cid:1)

(cid:3)(cid:1)

Relación con el sistema de tipos común y con
Common Language Specification

El Sistema de tipos común es el modelo que define las reglas que se siguen en Common Language
Runtime para declarar, utilizar y administrar tipos. Este sistema establece un marco de trabajo que
permite la integración entre lenguajes, la seguridad de tipos y ejecutar código de alto rendimiento.
Es la materia prima a partir de la cual se pueden crear bibliotecas de clases.

Common Language Specification (CLS) define un conjunto de reglas comprobables mediante
programación que determina la interoperación de los tipos creados en distintos lenguajes de
programación. La selección de CLS es un modo excelente de garantizar la interoperación entre
lenguajes. Los diseñadores de bibliotecas de clases administradas pueden utilizar CLS para
asegurarse de que las API creadas se pueden llamar desde una amplia gama de lenguajes de
programación. Tenga en cuenta que aunque CLS promueve el diseño correcto de bibliotecas, no lo
impone. Para obtener más información sobre este tema, vea Escribir código compatible con CLS.

Para determinar las funciones que se deben incluir en una biblioteca de clases, siga estos dos
principios orientativos con relación a CLS:

1. Determinar si la función facilita el tipo de desarrollo API adecuado al espacio administrado.

CLS debe ser lo suficientemente completo como para permitir escribir cualquier tipo de
biblioteca administrada. No obstante, si proporciona múltiples formas de realizar una misma
tarea, puede desorientar al usuario de la biblioteca de clases a la hora de decidir sobre la
utilización y el diseño correctos. Por ejemplo, si
incluye construcciones seguras y
construcciones no seguras los usuarios deberán elegir entre estas dos opciones. Por
consiguiente, CLS fomenta el uso correcto porque ofrece sólo construcciones con seguridad de
tipos.

2. Determinar si para el compilador puede ser difícil exponer la función.

Todos los lenguajes de programación requerirán algún tipo de modificación para que se
adapten al tiempo de ejecución y al sistema de tipos común. Sin embargo, para que los
programadores puedan hacer que un lenguaje sea compatible con CLS, no necesitan crear una
gran cantidad de trabajo adicional. El objetivo de CLS es ser lo más pequeño posible a la vez
que ofrece un extenso conjunto de funciones y tipos de datos.

(cid:1)

(cid:1)

(cid:4)(cid:1)

Instrucciones de nomenclatura

La existencia de un modelo de nomenclatura coherente, es uno de los elementos más importantes
en cuanto a previsibilidad y capacidad de descubrimiento en una biblioteca de clases. El uso y el
conocimiento generalizados de estas instrucciones de nomenclatura debería eliminar la mayoría de
las preguntas más frecuentes de los usuarios. En este tema se proporcionan instrucciones de
nomenclatura para los tipos de .NET Framework. En cada tipo, deberá tener en cuenta también
algunas de las reglas generales con relación a los estilos de mayúsculas, distinción entre
mayúsculas y minúsculas y elección de palabras.

(cid:1)

(cid:1)

(cid:5)(cid:1)

Estilos de mayúsculas

Utilice las tres convenciones siguientes para poner en mayúsculas los identificadores.
#Mayúsculas y minúsculas Pascal

La primera letra del identificador y la primera letra de las siguientes palabras concatenadas están en
mayúsculas. El estilo de mayúsculas y minúsculas Pascal se puede utilizar en identificadores de
tres o más caracteres. Por ejemplo:
BackColor
#Mayúsculas y minúsculas Camel

La primera letra del identificador está en minúscula y la primera letra de las siguientes palabras
concatenadas en mayúscula. Por ejemplo:
backColor

Mayúsculas

Todas las letras del identificador van en mayúsculas. Utilice esta convención sólo para
identificadores que estén formados por dos o menos letras. Por ejemplo:
System.IO

System.Web.UI

Además, puede que sea necesario utilizar mayúsculas en los identificadores para mantener la
compatibilidad con esquemas existentes de símbolos no administrados, donde los caracteres en
mayúsculas se utilizan con frecuencia en valores de constantes y enumeraciones. En general, estos
símbolos no deben ser visibles fuera del ensamblado en el que se utilizan.

En la tabla siguiente se resumen las reglas de uso de mayúsculas y se proporcionan ejemplos de
los diferentes tipos de identificadores.


Uso
mayúsculas
minúsculas

Ejemplo

de
o

Identificador

Class

Tipo Enum

Valores enum

Evento

Pascal

Pascal

Pascal

Pascal

AppDomain

ErrorLevel

FatalError

ValueChange

WebException

Nota Termina siempre con el sufijo Exception.

RedValue

Clase
excepciones

de

Pascal

Campo estático de
sólo lectura

Pascal

(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)(cid:1)

(cid:6)(cid:1)(cid:7)(cid:8)(cid:7)(cid:9)(cid:10)(cid:11)(cid:12)(cid:13)(cid:14)(cid:10)(cid:15)(cid:16)(cid:17)(cid:14)(cid:18)(cid:19)(cid:20)(cid:14)(cid:10)(cid:19)(cid:21)(cid:22)(cid:10)(cid:7)(cid:23)(cid:9)(cid:24)(cid:2)(cid:1)

(cid:6)(cid:1)(cid:7)(cid:8)(cid:7)(cid:9)(cid:10)(cid:11)(cid:12)(cid:13)(cid:14)(cid:10)(cid:15)(cid:16)(cid:17)(cid:14)(cid:18)(cid:19)(cid:20)(cid:14)(cid:10)(cid:19)(cid:21)(cid:25)(cid:12)(cid:13)(cid:19)(cid:20)(cid:25)(cid:12)(cid:21)(cid:14)(cid:10)(cid:15)(cid:22)(cid:10)(cid:7)(cid:23)(cid:9)(cid:24)(cid:3)(cid:1)

(cid:1)

Interfaz

Método

Espacio
nombres

Parámetro

Propiedad

Pascal

Pascal

de

Pascal

Camel

Pascal

de
Campo
instancia protegido

Camel

Campo
instancia público

de

Pascal



IDisposable

Nota Comienza siempre con el prefijo I.

(cid:26)(cid:1)

ToString

System.Drawing

typeName

BackColor

redValue

Nota Se utiliza en contadas ocasiones. Es
preferible utilizar una propiedad, en vez de un
campo de instancia protegido.

RedValue

Nota Se utiliza en contadas ocasiones. Es
preferible utilizar una propiedad, en vez de un
campo de instancia público.

(cid:1)

(cid:1)

(cid:1)

(cid:27)(cid:1)

Distinción de mayúsculas y minúsculas

Para evitar confusiones y garantizar la interoperación entre lenguajes, siga estas reglas con
respecto a la distinción entre mayúsculas y minúsculas:

• No utilice nombres que requieran distinción entre mayúsculas y minúsculas. Los componentes
se deben poder utilizar en los lenguajes que distinguen, y en los que no distinguen, entre
mayúsculas y minúsculas. Los lenguajes que no hacen esta distinción no pueden diferenciar,
dentro del mismo contexto, dos nombres que difieren sólo en el uso de mayúsculas y
minúsculas. Por consiguiente, se debe evitar esta situación en los componentes o clases
creados.

• No debe crear dos espacios de nombres con nombres que difieran sólo en las mayúsculas y
minúsculas. Por ejemplo, un lenguaje que no haga distinción entre mayúsculas y minúsculas no
distingue entre las dos declaraciones siguientes de espacio de nombres.

namespace ee.cummings;

namespace Ee.Cummings;

• No debe crear una función con nombres de parámetros que difieran sólo en las mayúsculas y

minúsculas. El siguiente ejemplo es incorrecto.

void MyFunction(string a, string A)

• No cree un espacio de nombres con nombres de tipos que difieran sólo en las mayúsculas y
minúsculas. En el siguiente ejemplo, Point p y POINT p son nombres de tipo incorrectos ya que
difieren sólo en el uso de las mayúsculas y minúsculas.

System.Windows.Forms.Point p

System.Windows.Forms.POINT p

• No debe crear un tipo con nombres de propiedades que d