Unidad Docente B: Clases y objetos

Tema 2. La estructura estática:

Clase
1. Concepto de clase
2. Sistemas
3. Ocultación de la Información

2º Grado en Ingeniería Informática – Metodología de la Programación

Autor: Raúl Marticorena Sánchez - Área de Lenguajes y Sistemas Informáticos – Dpto. Ingeniería Informática
UNIVERSIDAD DE BURGOS
 Objetivos
• Conocer el concepto estático de
clase en orientación a objetos
• Comprender el concepto de
sistema a partir de las clases
• Conocer la idea y utilidad de la
ocultación de propiedades en
los módulos/clases
1. Concepto de clase
• Definición: Es un tipo (abstracto) de datos equipado con
una posible implementación parcial o total
• Tipo Abstracto de Datos (TAD): noción matemática
útil en especificación
– Define instancias "matemáticas" como elementos
de un conjunto

• Clase: diseño e implementación vinculados a la

construcción del software
– Define instancias como estructuras representables
en una memoria y manipuladas por software
– Los objetos son las instancias de esa clase
– Si la implementación es total: Clase concreta o
efectiva
– Si la implementación es parcial: Clase abstracta o
diferida

UNIVERSIDAD DE BURGOS 3/25

1. Concepto de clase

• Doble papel:
– Módulo: unidad de descomposición del software
– concepto sintáctico
– Recordad: módulo, paquetes, agrupación (Cluster en Eiffel),
espacio de nombres (Namespaces en .NET/packages en Java),etc.
– Tipo: descripción estática de ciertos objetos dinámicos
– concepto semántico

• Dualidad Módulo-Tipo
Las facilidades de la clase A, vista como módulo, son las
operaciones disponibles de las instancias (ejemplares,
objetos) de A, vista como tipo.

• Propiedad fundamental
Todo objeto es una instancia de alguna clase

UNIVERSIDAD DE BURGOS 4/25

1. Concepto de clase

• Cuatro mundos del desarrollo software

Molde Instancia

Abstracto TAD Modelo de objetos

Concreto Clase Objetos (Software)

Leyenda Implementa
Instancia de

UNIVERSIDAD DE BURGOS 5/25

1. Concepto de clase

• Propiedades representadas en el “espacio” (memoria) o

en el “tiempo” (calculadas)
– Almacenadas (atributos) vs. Calculadas (rutinas)

Representación Cartesiana Representación Polar

Almacenando x,y: Almacenando p,  :
p = x2  y2 x = p cos 
 = arctg (y /x) y = p sin 

x p
y 

UNIVERSIDAD DE BURGOS 6/25

 1. Concepto de clase

• Rutinas:
– Devuelven un resultado  FUNCIONES
– No devuelven nada  PROCEDIMIENTOS

Funciones Procedimientos
p = x2  y2 trasladar
 = arctg (y /x) rotar
escalar

UNIVERSIDAD DE BURGOS 7/25

Nota: no confundir la noción de función en TAD con la función en Clases
2. Sistemas

• Construcción de software OO
– Para obtener código ejecutable ensamblamos un
conjunto de clases

• Si se produce el cierre correcto del sistema una herramienta

puede generar a partir de la clase raíz y las clases
referenciadas, un sistema ejecutable.

Cierre de un sistema

Un sistema esta cerrado, si y solo si, su conjunto de clases

contiene todas las clases necesarias por la clase raíz.

UNIVERSIDAD DE BURGOS 8/25

2. Sistemas

• Requisitos para un nuevo sistema:

– Un conjunto de clases (CS) de sistema

– Determinar la clase raíz del CS

– Determinar el procedimiento de la clase raíz que es

el procedimiento raíz de creación
• Ej: en Java a través del método
– public static void main(String[] args){ … }

UNIVERSIDAD DE BURGOS 9/25

2. Sistemas

• Cierre del sistema

– Propiedades:

• Una clase C necesita directamente D, si el texto de C se

refiere a D (cliente o hereda).
– Ej : D a; en el código de la clase C

• La clase C necesita a E si C es E o C necesita

directamente una clase D que (recursivamente)
necesita E.
E

UNIVERSIDAD DE BURGOS 10/25

2. Sistemas

• ¿Pero no estamos ante un “main” de nuevo?

– Antes se mezclaban dos ideas no relacionadas:

• El punto de arranque
• La cima o componente fundamental del sistema software

– Es necesario un punto de arranque

• Clase raíz y procedimiento de creación

– Pero NO asumimos que el punto de arranque es el

objetivo y pieza fundamental de la arquitectura del
sistema

UNIVERSIDAD DE BURGOS 11/25

2. Sistemas
• Ensamblado de sistemas
– No se debe introducir texto en las clases (Ej: Eiffel) o por lo
menos no introducir dependencias físicas o locales (Ej:
Java, .NET)
– ¿Solución?  Describir externamente en otros recursos:
• las dependencias
• localizaciones físicas

• Ej: en Java, se usa el concepto de paquete (package) y

CLASSPATH
• Ej: en Eiffel, lenguaje Lace, concepto de agrupación (cluster)

• Los sistemas dan soporte a los agrupamientos

(paquetes/cluster) a través del concepto de directorio
– los ficheros a seleccionar se toman por su extensión en cada
directorio
– se sigue el criterio de que el fichero se llame como la clase que
contiene

• Como resultado se obtiene un "ejecutable"

UNIVERSIDAD DE BURGOS 12/25

 2. Sistemas
Caso de estudio: ensamblaje de sistemas en Java

Paquete
– es una colección de clases relacionadas que se combinan con
otros paquetes para construir aplicaciones (sistemas)

– Contienen:
• clases, interfaces, subpaquetes y recursos como imágenes,
ficheros de texto, etc.

– Resuelve las colisiones de nombres

• Convención de código: nombres de paquetes y subpaquetes en
minúsculas separados por puntos

– En el código fuente de la clase se indica su pertenencia a un

paquete

– Si no se indica nada pertenecen al paquete "anónimo" o paquete

por defecto
OJO. En las primeras – No recomendable su uso
sesiones prácticas lo
hemos utilizado pero
• Nota: la jerarquía de clases del núcleo de Java está organizada como
a medida que avance colecciones de paquetes y subpaquetes
el curso dejaremos de
usarlo. UNIVERSIDAD DE BURGOS 13/25
2. Sistemas
• Declaración del paquete al que pertenece la clase en su código fuente:
– package nombrepaquete;
• define un paquete al que pertenecerán las clases del fichero.

• Nombre completo cualificado = nombre de un tipo precedido por el nombre de su

paquete (y subpaquetes) utilizando el punto como separador
– Nota: también llamado nombre canónico
• Ej: java.lang.String

• Nombre simple = nombre del tipo

• Ej: String

• Importar clases de otros paquetes:

– Importación de tipo único
• import <nombrepaqueteysubpaquetes>.<tipo>;
– Nota1: si intentamos importar dos tipos únicos con igual nombre simple, genera un error en compilación
– Nota2: tiene mayor precedencia que otro tipo con igual nombre simple importado bajo demanda, u otro tipo en el mismo paquete con el
mismo nombre simple (a este efecto se le llama "sombrear")
– Importación bajo demanda
• import <nombre_paquete_y_subpaquetes>.*;

package com.tex; // nombre de paquete

• Ej: import java.awt.Panel; // importación de tipo único
import java.util.*; // importar bajo demanda
public class MiClase {
// el resto de código de la clase
}

UNIVERSIDAD DE BURGOS 14/25

2. Sistemas
• Paquetes
– Se organizan en forma jerárquica
• Contienen clases
• Se corresponden con directorios y
ficheros .class java
• o directorios empaquetados en .jar
o .zip

awt lang util

– Ejemplo:
• java.lang.String
• java.util.Vector
• java.awt.Component
• java.awt.color.ColorBase color Component

String System
ref

ColorSpace

UNIVERSIDAD DE BURGOS 15/25

2. Sistemas

• ¿Donde se buscan las clases de usuario en compilación y ejecución?

– Solución 1: especificar rutas con el parámetro –classpath (o –cp) en las
herramientas del SDK. Ej: java, javac, etc.
– Solución 2: variable de entorno CLASSPATH
• Se indica: . 
– directorios donde buscar nuestros ficheros .class
– ficheros contenedores de clases .jar o .zip
» A partir de Java 6 se pueden añadir con /* 
• CLASSPATH por defecto = directorio actual
– Se sobrescribe con la variable de entorno o utilizando –classpath
• Debemos añadir el directorio actual (.) en dichos casos

• Ejemplos: definición de variables de entorno (dependiendo del sistemas
operativo)

– Windows - en el Panel de Control / Sistema / Entorno Avanzado / Variables de Entorno

– UNIX – GNU/Linux depende del shell
• Puede ir en ficheros .profile y .bashrc particulares o en un fichero nuevo tipo
/etc/profile.d/jdk.sh para todos los usuarios.
• Ejemplo: GNU BASH: export CLASSPATH="value";

UNIVERSIDAD DE BURGOS 16/25

2. Sistemas
• Búsqueda de las clases
• En compilación hay que indicar donde buscar los ficheros fuente en relación con las rutas de
directorios actuales
– Ej: javac .\paquete1\subpaquete2\subpaquete3\HolaMundo.java (win)

• En ejecución
– Es necesario utilizar el nombre completo cualificado de la clase raíz

• En ambos casos CLASSPATH correcto para localizar clases necesarias a partir del punto inicial de
compilación o ejecución
.
– Ejemplo:
Ejecutamos desde aquí…
paquete1
package paquete1.subpaquete2.subpaquete3;
public class HolaMundo{
 subpaquete2
...
public static void main(String args[])
{ ... }  subpaquete3
... código fuente
} asociado al
fichero .class HolaMundo.class
HolaMundo.class

– java paquete1.subpaquete2.subpaquete3.HolaMundo

UNIVERSIDAD DE BURGOS 17/25

2. Sistemas
• Búsqueda (Pasos):

– 1. Determinar si la clase pertenece al paquete interno

java.lang.* o al propio paquete
– Nota: no es necesario importar el paquete java.lang.* o el propio paquete,
se hace de manera automática

– 2. En caso contrario busca en las sentencias import declaradas:

– Ejemplo: import com.mmm.nnn.Clase;

• Para cada sentencia import

– se mira secuencialmente buscando la clase "desconocida" utilizando el valor
de la variable CLASSPATH

• Si no encuentra ninguna (clase no encontrada) o encuentra más de una

(ambigua)=> ERROR

• Nota: es posible no tener que importar el paquete y referirnos a la clase con la ruta
completa (en la práctica casi no se usa salvo colisiones sin otra solución):
– Ejemplo: com.mmm.nnn.Clase c=new com.mmm.nnn.Clase();

UNIVERSIDAD DE BURGOS 18/25

2. Sistemas
• Ejemplo
– SET CLASSPATH=.;\jdk-16.0.2\lib (win)

– Buscamos la clase xxx.yyy.zzz.ClaseA

– Empieza buscando en el directorio actual un subdirectorio
llamado xxx.
– Si lo encuentra busca un nuevo subdirectorio yyy.
– Si lo encuentra busca un nuevo subdirectorio zzz.
– En ese subdirectorio busca el archivo ClaseA.class
– Generado a partir de un código fuente ClaseA.java cuya primera línea de código es package
xxx.yyy.zzz;

– Si alguno de estos pasos falla

• lo intenta de nuevo en el siguiente directorio marcado (lib en
nuestro caso) hasta encontrar la clase.
– Si al final del proceso no se encuentra se generan errores
– Truco: es conveniente mantener un CLASSPATH corto por razones de
rendimiento.

UNIVERSIDAD DE BURGOS 19/25

3. Ocultación de la información
●
Cada módulo debe mostrar solo un subconjunto de
propiedades disponibles para los autores de módulos
cliente.

– Metáfora del iceberg...

•Accesibles para todos

•No debe cambiar la forma de invocación Parte Pública
•Establece el “contrato”

• No accesibles
• Detalles de implementación Parte Privada
• Sin restricciones en cuanto a cambios
siempre que la clase siga siendo “correcta”.

UNIVERSIDAD DE BURGOS 20/25

3. Ocultación de la información
• Restringir por mecanismos del lenguaje:

– Java, C#  modificadores de acceso a miembros

• Ej: modificadores en Java
– private, acceso restringido a la propia clase
– "amigable“ (sin especificar), acceso
restringido a las clases del mismo grupo
– protected, acceso restringido a las clases
que heredan y del mismo paquete
– public, acceso público a todas las clases

– Eiffel  listas de exportación a clientes

• Ej: feature { } h;
• Ej: feature {CLASEA, CLASEB} f;

UNIVERSIDAD DE BURGOS 21/25

3. Ocultación de la información

JAVA package
Nivel de visibilidad
public
“amigo”
"amigable"
protected

Clase private Clase

Acceso

Herencia
Clase Clase

UNIVERSIDAD DE BURGOS 22/25

 Conclusión

●
Los módulos / clases implementan tipos
– Con propiedades: estado (atributos) y comportamiento (rutinas)
– Es un concepto estático
• Hasta que no ejecutamos no tendremos “objetos”
●
Las clases se ensamblan para formar un sistema en ejecución
– Fundamental el uso de paquetes e importaciones en Java
●
Las clases ocultan detalles de implementación a los clientes
– En Java, mediante el uso de modificadores de acceso incluidos en el
lenguaje

UNIVERSIDAD DE BURGOS 23/25

Referencias
• Construcción de Software Orientado a Objetos (1998) Meyer, B.
Editorial Prentice Hall, 2ª Ed.
– Capítulo 7. La estructura estática: Clase

• Lecturas recomendadas
– [Eckel 2007]. Eckel, B. (2007). Piensa en Java. (4ª
Edición). Prentice Hall.
• Capítulo 6. Control de Acceso

– Convenciones de Nombres en Java

• Code Conventions for the Java Programming
Language. Sun Microsystems, Inc
– Chapter 9. Naming Conventions
• Disponible en línea en:
http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

UNIVERSIDAD DE BURGOS 24/25

 Licencia

Autor: Raúl Marticorena Sánchez

Área de Lenguajes y Sistemas Informáticos
Departamento de Ingeniería Informática
Escuela Politécnica Superior
UNIVERSIDAD DE BURGOS
Septiembre 2021

Este obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Unported.
No se permite un uso comercial de esta obra ni de las posibles obras derivadas, la distribución de las cuales se debe
hacer con una licencia igual a la que regula esta obra original

Licencia disponible en https://creativecommons.org/licenses/by-nc-sa/4.0/