Unidad 2 / Escenario 4

Lectura Fundamental

Proceso de análisis y diseño

orientado a objetos

Contenido

1 Proceso de análisis y diseño orientado a objetos 1

2 Definición de propiedades y comportamientos 9

3 Representación gráfica: diagrama de clases Triqui 9

4 Introducción al acoplamiento y cohesión 20

5 Encapsulamiento para reducir el acoplamiento 21

Palabras claves: programación orientada a objetos, análisis orientado a objetos, diseño orientado a objetos,
acoplamiento, cohesión
El terminar el desarrollo de una aplicación y lograr que funcione correctamente, no indica que esté bien estructurada
internamente, ni mucho menos que el diseño de las clases sea el adecuado. Si las clases están mal diseñadas, es
posible que existan problemas cuando se trate de modificar o extender la aplicación, empleando una gran cantidad
de trabajo.

En esta lectura usaremos como ejemplo un juego clásico denominado Triqui, el cual será sometido a modificaciones
y extensiones de la aplicación original, que deberı́an ser fáciles y obvias con un buen diseño de clases. Además,
tendremos la oportunidad de discutir algunos aspectos de diseño relevantes en la estructura de clases.

Triqui (también llamado Tres en Lı́nea, Juego del Gato, Ta-Te-Ti, entre otros) es un viejo juego que se desarrolla
entre dos jugadores, que eligen una marca que los representa (O y X). Los jugadores colocan su marca en el tablero
de 9 casillas o celdas de manera alternativa. Un jugador gana si consigue tener una lı́nea de tres casillas seguidas
con su marca: la lı́nea puede ser horizontal, vertical o diagonal. Si se acaban las casillas libres y ningún jugador
hizo una lı́nea de tres, se determina un empate.

Además, observaremos que algunas decisiones de diseño en la implementación del juego inicial fueron mal tomadas,
ocasionando un impacto maligno en el desarrollo de la aplicación, que será corregido mostrando los motivos por los
que está mal y cómo se pueden solucionar.

1. Proceso de análisis y diseño orientado a objetos

Al trabajar con el paradigma de programación orientado a objetos, es necesario abstraer los elementos del mundo
real que nos interesan a través del proceso de análisis y diseño orientado a objetos. Este proceso pretende establecer
un conjunto de objetos que serán definidos como parte de la solución del problema que nos atañe, obteniendo para
cada uno de los objetos información de sus atributos y comportamiento, y las relaciones que puedan tener con
otros objetos.

Ahora, trabajemos en el problema que tenemos. Lo primero que debemos hacer es definir qué objetos del mundo real
queremos modelar. Para hacerlo, nos podemos guiar por una lista inicial basada en la identificación de sustantivos
en un texto. Como podemos ver, los sustantivos hallados inicialmente están resaltados con negrita.

Triqui (también llamado Tres en Lı́nea, Juego del Gato, Ta-Te-Ti, entre otros) es un viejo juego que se
desarrolla entre dos jugadores, que eligen una marca que los representa (O y X). Los jugadores colocan su
marca en el tablero de 9 casillas o celdas de manera alternativa. Un jugador gana si consigue tener una lı́nea
de tres casillas seguidas con su marca: la lı́nea puede ser horizontal, vertical o diagonal. Si se acaban las casillas
libres y ningún jugador hizo una lı́nea de tres, se determina un empate.

Como se puede ver en la lista de la figura No. 1, se muestra el primer conjunto de candidatos a convertirse en clase
de objetos.

POLITÉCNICO GRANCOLOMBIANO 1
 Figura No. 1: primera lista de sustantivos candidatos.

El segundo paso es eliminar de la lista inicial los sustantivos repetidos. Realizaremos el proceso paso a paso para
mostrar qué sustantivos se eliminan y por qué.

1.1. Triqui, tres en lı́nea, juego del gato, Ta-Te-Ti y juego.

En este caso se mencionan tres sintagmas nominales que hacen el papel de sustantivos propios (Tres en lı́nea,
juego del gato, Ta-Te-Ti y Triqui) y el sustantivo común (Juego). Todos ellos hacen referencia al mismo juego. Sin
embargo, algunos de ellos representan mejor a la entidad, y por esta razón escogeremos solo uno de ellos, para que
represente al conjunto de objetos. Para nuestro diseño se escogerá el objeto Triqui, que es un elemento del mundo
real que nos interesa modelar (ver figura No. 2).

Figura No. 2: segunda lista de sustantivos, primer proceso de eliminación.

1.2. Jugador y jugadores.

Son sustantivos comunes, de género masculino, singular y plural (respectivamente), se repiten cuatro veces haciendo
referencia al mismo objeto jugador. Recuerde que los sustantivos deben estar en singular; por esta razón se

POLITÉCNICO GRANCOLOMBIANO 2
eliminarán todos los sustantivos que se encuentran en plural y se dejará en la lista solo un sustantivo que represente
al objeto jugador (ver figura No. 3).

Figura No. 3: segunda lista de sustantivos, segundo proceso de eliminación.

1.3. Marca.

Este sustantivo común se encuentra repetido tres veces en la lista, y se eliminarán dos de los sustantivos repetidos
(ver figura No. 4).

Figura No. 4: segunda lista de sustantivos, tercer proceso de eliminación.

1.4. X y O

Estos sustantivos no están repetidos , se mantienen en la lista (ver lista figura No. 5).

POLITÉCNICO GRANCOLOMBIANO 3
 Figura No. 5: segunda lista de sustantivos, cuarto proceso de eliminación.

1.5. Tablero

El sustantivo común Tablero no está repetido y es un objeto del problema que nos interesa modelar, por lo que
continúa en la lista (ver figura No. 6)

Figura No. 6: segunda lista de sustantivos, quinto proceso de eliminación.

1.6. Casillas o celdas.

Los dos sustantivos representan el mismo objeto; sin embargo, tenemos que escoger el que más se ajuste a la
solución del problema que nos interesa. Una casilla es un compartimento en que se divide el tablero de un juego,
mientras que una celda hace referencia a una habitación o cuarto donde habitan diferentes tipos de personas.

Se eliminará de la lista el sustantivo celda, debido a que el sustantivo casilla se ajusta más al objeto que hace parte
de la solución del problema. Además, el sustantivo común en plural casillas se eliminará y se creará el sustantivo
común en singular casilla (ver figura No. 7)

POLITÉCNICO GRANCOLOMBIANO 4
 Figura No. 7: segunda lista de sustantivos, sexto proceso de eliminación.

1.7. Lı́nea

Para este caso, una lı́nea es un conjunto de tres casillas, que puede ser horizontal, vertical o diagonal y hace parte
del tablero, y que además nos sirve para evaluar si algún jugador ganó. Este sustantivo común se encuentra repetido
tres veces en la lista, y por tanto se eliminarán dos de los sustantivos repetidos (ver figura No. 8).

Figura No. 8: segunda lista de sustantivos, séptimo proceso de eliminación.

1.8. Tablero

Por último, el sustantivo abstracto empate no está repetido, y continúa en la lista (ver figura No. 9).

POLITÉCNICO GRANCOLOMBIANO 5
 Figura No. 9: segunda lista de sustantivos, octavo proceso de eliminación.

Como resultado del segundo paso se obtiene una lista depurada de sustantivos del conjunto de candidatos a objetos
(ver figura No. 10).

Figura No. 10: segunda lista de sustantivos, listado final.

El tercer paso es descartar las clases que se encuentren definidas previamente en el lenguaje de programación en el
cual se desarrollará la aplicación, en nuestro caso, en Java. Ninguno de los objetos de la lista tiene una definición
previa de una clase que los represente en Java. Se mantiene por tanto la misma lista (ver figura No. 11)

Figura No. 11: tercera lista de sustantivos, listado final.

POLITÉCNICO GRANCOLOMBIANO 6
1.8.1. Marca

Este sustantivo común es una propiedad del objeto casilla, y si profundizamos un poco más en el objeto casilla, nos
daremos cuenta que una casilla tiene una marca, lo que quiere decir que marca es un atributo de la casilla que
puede almacenar un carácter (‘X’ o ‘O’ o ‘ ’ ), no un objeto por sı́ mismo. Este sustantivo debe ser eliminado de la
lista (ver figura No. 12).

Figura No. 12: cuarta lista de sustantivos, primer proceso de descarte: sustantivo marca.

1.8.2. X y O

Aunque son sustantivos, no representan ningún objeto o entidad del problema, sino que en realidad los podemos
considerar como posibles valores que pueden ser asignados a la marca. Estos sustantivos deben ser eliminados de
nuestra lista (ver lista figura No. 13).

Figura No. 13: cuarta lista de sustantivos, segundo proceso de descarte: sustantivo X y O.

1.8.3. Lı́nea

Para este caso, una lı́nea es un conjunto de tres casillas, que puede ser horizontal, vertical o diagonal y hace parte
del tablero, y además nos sirve para evaluar si algún jugador ganó. Sabemos que el tablero tiene nueve casillas y
que las organiza en lı́neas, lo cual quiere decir que la o las lı́neas son una propiedad del tablero y no representan un
objeto. Por esta razón el sustantivo lı́nea será eliminado de la lista (ver lista figura No. 14).

POLITÉCNICO GRANCOLOMBIANO 7
 Figura No. 14: cuarta lista de sustantivos, tercer proceso de descarte: sustantivo lı́nea.

1.8.4. Empate

Por último, el sustantivo empate, no es un objeto del problema, y no tiene atributos y comportamientos explı́citos,
sino que de cierta forma es un comportamiento del juego que veremos en el desarrollo de los métodos. Por ello, a
este sustantivo se eliminará de la lista (ver figura No. 15).

Figura No. 15: cuarta lista de sustantivos, tercer proceso de descarte sustantivo Empate.

Como resultado del cuarto paso, se obtiene una lista de sustantivos depurada del conjunto de candidatos a objetos
(ver figura No. 16).

Figura No. 16: cuarta lista de sustantivos, lista final.

Podrı́amos decir entonces que la lista resultante en el cuarto paso del proceso de análisis y diseño orientado a
objetos es la lista de objetos que vamos a modelar para responder a las necesidades que plantea el problema. El
siguiente paso es definir qué propiedades y comportamientos posee cada objeto.

POLITÉCNICO GRANCOLOMBIANO 8
2. Definición de propiedades y comportamientos

Comenzaremos por analizar los objetos a modelar, los cuales son: Triqui, Tablero, Casilla y Jugador.

Casilla. Una casilla deberı́a conocer la marca que puede ser asignada en ella. En nuestro caso, solo existen tres
posibles caracteres (‘X’ o ‘O’ o ‘ ’) y solo se pueden asignar si la casilla esta vacı́a (‘ ’). La marca es inherente a la
casilla y deberı́a ser modelada, lo cual quiere decir que en la definición de la clase deberı́a estar la propiedad marca.

Tablero. Si hablamos del tablero, este tiene 9 casillas, y podrı́amos decir que algunos de sus comportamientos
serian: saberse pintar, dado que estamos hablando de un componente grafico, validar si un jugador gana de acuerdo
a la validación en las lı́neas de tres casillas seguidas con su marca: horizontal, vertical o diagonal, y además asignar
la marca del jugador en una posición especifica del tablero.

Jugador. Un jugador tiene una marca, un nombre y un puntaje.

Triqui. Finalmente, un Triqui se desarrolla en un tablero entre dos jugadores que eligen una marca que los
representa (‘O’ y ‘X’). Los jugadores asignan su marca en una posición determinada en el tablero de 9 casillas que
posee el Triqui, hasta que alguno haga Triqui (gane) o se acaben las casillas libres y se declare un empate.

La información definida hasta ahora bastarı́a para contar con una aproximación inicial de lo que puede ser un
Triqui. Ahora hablemos un poco de la forma de representar clases de objetos en un lenguaje de programación, o
gráficamente con ayuda de un diagrama de clases.

3. Representación gráfica: diagrama de clases Triqui

El objetivo de un diagrama de clases es plasmar las caracterı́sticas de los objetos y las relaciones que tienen
estos objetos entre sı́. Cada uno de nuestros objetos (Triqui, Jugador, Tablero y Casilla), poseen propiedades y
comportamientos que son descritos en una clase que representa al objeto (categorı́a de objetos). Esta conversión
se realiza porque el diagrama de clases se basa en la representación de clases como elementos de un sistema que
interactúan entre si para lograr un objetivo.

Cada clase se representa con un rectángulo con el nombre de la clase (ver figura No 17).

POLITÉCNICO GRANCOLOMBIANO 9
 Figura No. 17: diagrama de clases Triqui. Nombre de las clases.

Además de su nombre, debemos definir variables y los métodos de la clase. Los atributos se ubican debajo del
nombre de la clase (ver figura No. 18), definiendo su modificador de acceso (ver capitulo x), nombre, su tipo y
otros elementos que se verán más adelante.

Los métodos se ubican en el siguiente espacio, especificando su nombre, su valor de retorno y sus parámetros. No se
presenta información de la lógica de los métodos. Ver figura No. 19.

Figura No. 18: diagrama de clases Triqui. Declaración de atributos.

Ahora ya definidos los atributos, es necesario explicar cómo se relacionan las clases. Para poder introducir este
tema, comenzaremos explicando el término de cardinalidad. En UML, la cardinalidad de las relaciones indica el
grado y nivel de dependencia, se anotan en cada extremo de la relación, de las siguientes formas:

POLITÉCNICO GRANCOLOMBIANO 10
 • Uno a muchos: 1. . . *
• 0 a muchos: 0. . . *
• Número fijo: m

En la figura No. 18, se puede observar los diferentes tipos de cardinalidad que existen entre las clases (número fijo),
por ejemplo, Un triqui se desarrolla en un tablero entre dos jugadores, además el tablero tiene 9 casillas.

Existen dos tipos de relaciones estáticas y dinámicas, en donde la relación estática el tiempo de vida del objeto
está condicionada por el tiempo de vida del que lo incluye. Este tipo de relación se conoce como relación por
Composición, por ejemplo, si se observa la figura No. 18, la relación que existe entre el objeto tablero y sus casilla
es una relación por composición, el tiempo de vida de las casillas está condicionado por el tiempo de vida del
objeto tablero, ya que este objeto las contiene.

El rombo negro se encarga de representar una relación por composición, siempre se encuentra ubicado en la clase
que es el “todo”, siguiendo nuestro ejemplo en la clase Tablero.

En cambio, la relación dinámica del tiempo de vida del objeto incluido es independiente del tiempo de vida del
objeto que lo incluye. Este tipo de relación se conoce como relación por agregación, observando la figura 2.18, la
relación que existe entre triqui y jugador es una relación por agregación, el tiempo de vida de objetos de tipo
jugador no está condicionado por el tiempo de vida del objeto triqui. En este caso el objeto base triqui utiliza a los
dos objetos jugador incluidos para su funcionamiento. Esta relación es de agregación debido a que los jugadores
pueden seguir jugando un nuevo triqui, no depende su tiempo de vida del triqui que estén jugando o al que
pertenezcan en un momento dado.

El rombo vacı́o se encarga de representar una relación por agregación, siempre se encuentra ubicado en la clase
que es el “todo”, siguiendo nuestro ejemplo en la clase Triqui.

Las relaciones entre clases como asociación, la cual permite asociar objetos que colaboran entre sı́. No es una
relación fuerte, como la relación por composición.

Figura No. 19: diagrama Inicial de clases Triqui.

POLITÉCNICO GRANCOLOMBIANO 11
3.1. Representación de clases en Java

public class Box {

//static constants
//SYMBOL_X
public static final String SYMBOL_X = "X";
//SYMBOL_O
public static final String SYMBOL_O = "O";
//SYMBOL_V
public static final String SYMBOL_V = " ";
//Variables
//box symbol
public String symbol;

/* Constructor
* Initialize the box by assigning the empty symbol
*/
public Box() {
this.symbol = SYMBOL_V;
}
/*
* Method
* Assign the symbol if it is X or O. Otherwise assign the empty symbol.
* @param c Symbol to be assigned
*/
public void assignSymbol(String c) {
String cTemp = c.trim().toUpperCase();
if(cTemp.equals(Box.SYMBOL_X) || cTemp.equals(Box.SYMBOL_O))
symbol = cTemp;
else
symbol = Box.SYMBOL_V;
}
/*
* Method
* Check if the box is empty
* @return true if is empty, otherwise return false
*/
public boolean isEmpty() {
return this.symbol.trim().isEmpty();
}
/*
* Method
* Evaluates whether the symbol of the box is equal to the symbol entered as a parameter
* @param c symbol to be evaluate
* @return true if the symbols are the same, otherwise false
*/
public boolean isEqual(String c) {
String cTemp = c.trim().toUpperCase();
return cTemp.equals(symbol);
}
}

Código 1: código fuente de la clase Casilla.

POLITÉCNICO GRANCOLOMBIANO 12
public class Player {
//Variables
//Symbol chosen by the player (X or O)
public String symbol;
//Accumulated score
public int score;
//Nickname of the player
public String nickname;

/*
* Default constructor
* Initializes the variable symbol, assigning the symbol and its nickname is empty
*/
public Player() {
this.symbol = Box.SYMBOL_O;
this.nickname = "";
}
/*
* Default constructor
* Initializes the symbol and nickname with the parameter
*/
public Player(String a, String c) {
this.symbol = c;
this.nickname = a;
}
}

Código 2: código fuente de la clase Jugador.

POLITÉCNICO GRANCOLOMBIANO 13
public class Board {
//Variables
//box array
public Box[] boxes;
//count of used boxes
public int usedBoxes = 0;
/*
* Default constructor
*/
public Board() {
init();
}
/*
* Creates a board of 9 boxes, and assigns an object
* of type box in each position
*/
public void init() {
boxes = new Box[9];
for(int i = 0; i < boxes.length; i++) {
boxes[i] = new Box();
}
}
/*
* Method
* Assigns a s symbol to position p of the board
* @param s symbol to be assigned
* @param p position in the board [1 ... 9]
* @return true if assigned correctly, otherwise false
*/
public boolean assignSymbolBox(int p, String s) {
if(boxes[p - 1].isEmpty()) {
boxes[p - 1].assignSymbol(s);
usedBoxes++;
return true;
}
return false;
}
/*
* Method
* Evaluate if there is a winner in the top row
* @param symbol last used symbol
* @return true if there is triqui in the top row, otherwise false
*/
public boolean isTriquiTopRow(String symbol) {
if(boxes[0].isEqual(symbol) && boxes[1].isEqual(symbol) && boxes[2].isEqual(symbol))
return true;
return false;
}

Código 3: código fuente de la clase Tablero.

POLITÉCNICO GRANCOLOMBIANO 14
/*
* Method
* Evaluate if there is a winner in the central row
* @param symbol last used symbol
* @return true if there is triqui in the central row, otherwise false
*/
public boolean isTriquiCentralRow(String symbol) {
if(boxes[3].isEqual(symbol) && boxes[4].isEqual(symbol) && boxes[5].isEqual(symbol))
return true;
return false;
}
/*
* Method
* Evaluate if there is a winner in the bottom row
* @param symbol last used symbol
* @return true if there is triqui in the bottom row, otherwise false
*/
public boolean isTriquiBottomRow(String symbol) {
if(boxes[6].isEqual(symbol) && boxes[7].isEqual(symbol) && boxes[8].isEqual(symbol))
return true;
return false;
}
/*
* Method
* Evaluate if there is a winner in the left column
* @param symbol last used symbol
* @return true if there is triqui in the left column, otherwise false
*/
public boolean isTriquiLeftColumn(String symbol) {
if(boxes[0].isEqual(symbol) && boxes[3].isEqual(symbol) && boxes[6].isEqual(symbol))
return true;
return false;
}
/*
* Method
* Evaluate if there is a winner in the central column
* @param symbol last used symbol
* @return true if there is triqui in the left column, otherwise false
*/
public boolean isTriquiCentralColumn(String symbol) {
if(boxes[1].isEqual(symbol) && boxes[4].isEqual(symbol) && boxes[7].isEqual(symbol))
return true;
return false;
}
/*
* Method
* Evaluate if there is a winner in the right column
* @param symbol last used symbol
* @return true if there is triqui in the left column, otherwise false
*/
public boolean isTriquiRightColumn(String symbol) {
if(boxes[2].isEqual(symbol) && boxes[5].isEqual(symbol) && boxes[8].isEqual(symbol))
return true;
return false;
}

Código 4: (continuación) código fuente de la clase Tablero.

POLITÉCNICO GRANCOLOMBIANO 15
 /*
* Method
* Evaluate if there is a winner in the main diagonal (\)
* @param symbol last used symbol
* @return true if there is triqui in the main diagonal(\), otherwise false
*/
public boolean isTriquiMainDiagonal(String symbol) {
if(boxes[0].isEqual(symbol) && boxes[4].isEqual(symbol) && boxes[8].isEqual(symbol))
return true;
return false;
}
/*
* Method
* Evaluate if there is a winner in the secondary diagonal (/)
* @param symbol last used symbol
* @return true if there is triqui in the secondary diagonal(/), otherwise false
*/
public boolean isTriquiSecondaryDiagonal(String symbol) {
if(boxes[2].isEqual(symbol) && boxes[4].isEqual(symbol) && boxes[6].isEqual(symbol))
return true;
return false;
}
/*
* Method
* Paint the board, box by box showing its symbol
* @return complete board
*/
public String paintBoard() {
String board = " ";
for(int i = 0; i < boxes.length; i++) {
if(boxes[i].isEmpty())
board = board + "[" + (i + 1) + "]" + " ";
else
board = board + " " + boxes[i].symbol + " ";
if((i + 1) % 3 == 0)
board = board + "\n" + " ";
}
return board;
}
}

Código 5: (continuación) código fuente de la clase Tablero.

POLITÉCNICO GRANCOLOMBIANO 16
public class Triqui {
//Variables
//Triqui board
public Board = board;
public Player p1, p2;
/*
* Constructor
* Initializes player variables with received parameters
*/
public Triqui(Player p1, Player p2) {
init(p1, p2);
}
/*
* Initializes variables 1 and 2 with the received players
* and creates a new board
*/
public void init(Player p1, Player p2) {
board = new Board();
this.p1 = p1;
this.p2 = p2;
}
/*
* Method
* Assigns a s symbol to position p of the board using the method of Board1 object
* @param s symbol to be assigned
* @param p position in the board [1 ... 9]
* @return true if assigned correctly, otherwise false
*/
public boolean assignSymbolBox(int p, String s) {
return board.assignSymbolBox(p, s);
}
/*
* Method
* Evaluate if there is a tie, if the checkboxes are equal to 9
* @return true if there is a tie, otherwise false
*/
public boolean isTie() {
if(this.board.usedBoxes == 9)
return true;
else
return false;
}
/*
* Method
* Evaluate if there is a winner in any of the rows (top, central, bottom, leftColumn, centralColumn,
* rightColumn, mainDiagonal, secundaryDiagonal)
* @param symbol actual symbol
* @return true if there is triqui, otherwise false
*/
public boolean isTriqui(String symbol) {
if(board.isTriquiTopRow(symbol) || board.isTriquiCentralRow(symbol) ||
board.isTriquiBottomRow(symbol) || board.isTriquiLeftColumn(symbol) ||
board.isTriquiCentralColumn(symbol) || board.isTriquiRightColumn(symbol) ||
board.isTriquiMainDiagonal(symbol) || board.isTriquiSecondaryDiagonal(symbol))
return true;
return false;
}

Código 6: código fuente de la clase Triqui.

POLITÉCNICO GRANCOLOMBIANO 17
 /*
* Gets the next player to play
* @param cPlayer Current player
* @return returns the player to play in the next iteration
*/
public Player getCurrentPlayer(Player cPlayer) {
return (p1.equals(cPlayer))? p2 : p1;
}
/*
* Gets the player who chose the X mark
* @param p1 First player
* @param p2 Second Player
* @return returns the player who chose the X mark
*/
public static Player getFirstPlayer(Player p1, Player p2) {
if(p1.symbol.equals(Box.SYMBOL_X))
return p1;
else
return p2;
}
/*
* Paint the Board1
* @return returns the complete board
*/
public String paintBoard() {
return board.paintBoard();
}
}

Código 7: (continuación) código fuente de la clase Triqui.

POLITÉCNICO GRANCOLOMBIANO 18
import javax.swing.JOptionPane;

public class Main {

public static final String[] SELECT_VALUES = {"YES", "NO"};

public static void main(String[] args) {

boolean game = true;
String np1 = "", np2 = "", p1Symbol = "", p2Symbol = "";
while(game) {
JOptionPane.showMessageDialog(null, "...:::Welcome to Poli triqui:::...");
boolean correctData = false;
// The following section validates the data entered by the players
// You will not be allowed to add empty or repeated data
while(!correctData) {
np1 = JOptionPane.showInputDialog(null, "Enter the nickname of the first player",
"Poli Triqui", JOptionPane.QUESTION_MESSAGE);
if((np1 = np1.toUpperCase().trim()).isEmpty())
JOptionPane.showMessageDialog(null, "Error. The nickname of the first player can’t be empty",
"Error", JOptionPane.ERROR_MESSAGE);
else
correctData = true;
}
correctData = false;
while(!correctData) {
np2 = JOptionPane.showInputDialog(null, "Enter the nickname of the second player",
"Poli Triqui", JOptionPane.QUESTION_MESSAGE);
if((np2 = np2.toUpperCase().trim()).isEmpty())
JOptionPane.showMessageDialog(null, "Error. The nickname of the second player can’t be empty",
"Error", JOptionPane.ERROR_MESSAGE);
else {
if(np2.equals(np1))
JOptionPane.showMessageDialog(null, "Error. The nickname of the players can’t be equals",
"Error", JOptionPane.ERROR_MESSAGE);
else
correctData = true;
}
}
correctData = false;

p1Symbol = (String) JOptionPane.showInputDialog(null, np1 + " choose your symbol",

"Poli Triqui", JOptionPane.QUESTION_MESSAGE, null,
new String[] {Box.SYMBOL_X, Box.SYMBOL_O}, Box.SYMBOL_X);
boolean answer = true;
while(answer) {
p2Symbol = (String) JOptionPane.showInputDialog(null, np2 + " choose yout symbol",
"Poli Triqui", JOptionPane.QUESTION_MESSAGE, null,
new String[] {Box.SYMBOL_X, Box.SYMBOL_O}, Box.SYMBOL_X);
if(p1Symbol.equalsIgnoreCase(p2Symbol))
JOptionPane.showMessageDialog(null, np2 + " choose an option " +
((p2Symbol.equals(Box.SYMBOL_X)) ? Box.SYMBOL_O : Box.SYMBOL_X) + " por favor");
else
answer = false;
}

Código 8: código fuente de la clase Principal.

POLITÉCNICO GRANCOLOMBIANO 19
 Player p1 = new Player(np1, p1Symbol);
Player p2 = new Player(np2, p2Symbol);
Player currentPlayer = Triqui.getFirstPlayer(p1, p2);

Triqui triqui = new Triqui(p1, p2);

String tSymbol = currentPlayer.symbol;
int position = -1;

while(!triqui.isTriqui(tSymbol) && !(triqui.isTie())) {

tSymbol = currentPlayer.symbol;
JOptionPane.showMessageDialog(null, "Player turn : " +
currentPlayer.nickname + ", symbol: " + tSymbol);
JOptionPane.showMessageDialog(null, triqui.paintBoard());
position = (Integer) JOptionPane.showInputDialog(null,
currentPlayer.nickname + " Enter position [1..9]",
"Poli Triqui", JOptionPane.QUESTION_MESSAGE, null,
new Integer[] {1,2,3,4,5,6,7,8,9},"0");
if(triqui.assignSymbolBox(position, tSymbol)) {
if(!triqui.isTriqui(tSymbol))
currentPlayer =
triqui.getCurrentPlayer(currentPlayer);
else {
JOptionPane.showMessageDialog(null,
"...:::Congratulations:::..." + currentPlayer.nickname +
" you win");
break;
}
}
}
if(!triqui.isTriqui(tSymbol) && triqui.isTie()) {
JOptionPane.showMessageDialog(null, "Tie...");
}
JOptionPane.showMessageDialog(null, triqui.paintBoard());
String cont = (String) JOptionPane.showInputDialog(null,
"Do you want to play a new game?", "Polo Triqui",
JOptionPane.QUESTION_MESSAGE, null, Main.SELECT_VALUES,
Main.SELECT_VALUES[0]);
if(cont.equals(Main.SELECT_VALUES[0]))
game = true;
else
game = false;
}
}
}

Código 9: (continuación) código fuente de la clase Principal.

4. Introducción al acoplamiento y cohesión

En el diseño de clases existen algunos términos vitales que debemos tener en cuenta al momento de diseñar una
clase, como lo son el acoplamiento y la cohesión. Estos conceptos son centrales y nos serán de utilidad para evaluar

POLITÉCNICO GRANCOLOMBIANO 20
si se ha realizado un diseño de calidad.

El término acoplamiento hace referencia a la interconectividad entre las clases, y el grado de acoplamiento indica
cuán fuerte están conectadas estas clases. Si las clases presentan una conexión fuerte, su grado de acoplamiento será
alto, lo cual determina el grado de dificultad para realizar modificaciones en una aplicación. Imagine que necesita
realizar una modificación en una estructura de clases fuertemente acoplada. ¿Ya lo imaginó? Ahora concéntrese en
imaginar cuántas clases de esta estructura deben ser modificadas. En este escenario, un cambio en una clase hace
necesario cambiar otras clases. Este panorama es el que debemos evitar a toda costa, pues los cambios pueden ser
difı́ciles y consumir demasiado tiempo. Nuestro objetivo debe ser lograr un acoplamiento débil en la estructura de
nuestras clases, logrando que cada una de ellas sea altamente independiente.

Recuerde: No debemos esforzar por lograr un acoplamiento débil. Esto significa que debemos lograr que cada una
de las clases de nuestra aplicación sea altamente independiente.

Una de las preguntas que surge normalmente es la siguiente: ¿Cómo saber si logramos un acoplamiento débil entre
las clases de nuestra aplicación? La respuesta es afirmativa si se cumple la siguiente condición: Un sistema es
débilmente acoplado si al modificar una sola clase no debemos realizar cambios en ninguna otra y la aplicación
continúa funcionando. Siempre tenga presente que el acoplamiento mide el grado de dependencia entre dos o más
clases; mayor dependencia implica mayor acoplamiento.

Por otra parte, el termino cohesión hace referencia a la pertinencia de una clase como una entidad, o a cuánto se
ajusta un método a un comportamiento especifico. El grado de cohesión indica la calidad del diseño de clases. En
un sistema altamente cohesivo, cada método es responsable de una tarea o un comportamiento bien definido, y
cada clase es responsable de una entidad bien definida.

5. Encapsulamiento para reducir el acoplamiento

El uso de variables públicas es uno de los principales problemas de este ejemplo: todos los campos de las clases
fueron declarados públicos. Claramente, no se respetó una de las reglas más importantes de la programación
orientada a objetos: “Nunca usar campos públicos”. Al declarar públicos estos campos, se ha expuesto la forma
de almacenar la información en los campos de cada una de las clases, ocasionando un diseño de mala calidad,
quebrantando de esta forma el principio fundamental de diseño de clases de buena calidad: el encapsulamiento.

El encapsulamiento es una de las principales caracterı́sticas de la programación orientada a objetos, que nos permite
ocultar tanto el comportamiento o la forma de desarrollar ciertas operaciones, como su estructura interna y la
forma en que protege el estado del objeto (su información), dejando la interacción con los demás componentes
previamente definida.

Sugiere que sólamente la información sobre lo que puede hacer una clase debe estar visible desde el exterior, pero
no cómo lo hace. Para separar el qué del cómo, los campos o variables se deben declarar utilizando el modificador
de acceso privado (private), y usando métodos de acceso para acceder a ellas (getters). Se muestra el primer paso
de la modificación de la variable marca en la clase Casilla.

Una vez que se han hecho los cambios en la clase Casilla necesitamos cambiar la clase Tablero, en cualquier lugar

POLITÉCNICO GRANCOLOMBIANO 21
donde se acceda a la variable marca, utilizando ahora el método de acceso getMarca(), que retornará el valor de la
variable. Por ejemplo, en lugar de escribir:

this.casillas[i].marca;

Ahora escribimos:

this.casillas[i].getMarca()

POLITÉCNICO GRANCOLOMBIANO 22
Referencias

Gabbrielli, M. & Martini, S. (2010). Programming languages: principles and paradigms. Springer Science & Business
Media.
Louden, K. C. y col. (2011). Programming languages: principles and practices. Cengage Learning.
Sebesta, R. W. (2012). Concepts of programming languages (10.a ed.). Pearson.
Van Roy, P. & Haridi, S. (2004). Concepts, techniques, and models of computer programming (1.a ed.). The MIT
Press.
Watt, D. A. (2004). Programming language design concepts. John Wiley & Sons.

POLITÉCNICO GRANCOLOMBIANO 23
 INFORMACIÓN TÉCNICA

Módulo: Paradigmas de Programación

Unidad 2: Programación orientada a objetos
Escenario 4: Proceso de Análisis y Diseño
Orientado a Objetos

Autor: Diego Satoba

Asesor Pedagógico: Manuel Fernando Guevara

Diseñador Gráfico: Yinet Rodrı́guez
Asistente: Angie Laiton

Este material pertenece al Politécnico Grancolombiano.

Por ende, es de uso exclusivo de las Instituciones
adscritas a la Red Ilumno. Prohibida su reproducción
total o parcial.

POLITÉCNICO GRANCOLOMBIANO 24