este es el aporte de mis profesores a la educación

2. UNIDAD 1:BUENAS PRÁCTICAS DE PROGRAMACIÓN ORIENTADA A OBJETO
Tema: 1.2. Programación Orientada a Objetos.
Semana 2
Programación de Computadores III
ANYA M. BOLAÑO ARIAS
M.Sc. en ingeniería de Sistemas y Computación

3. Objetivos de aprendizaje
• Identificar los Fundamentos de la programación Orientada a Objetos con el fin de
desarrollar aplicaciones que den solución a problemas comunes del desarrollo de
software
• Identificar los factores que permiten un código limpio para que las soluciones
desarrolladas sean entendible por el equipo de desarrollo.
• Conocer la arquitectura en capas con el fin de establecer un marco de referencia para
guiar la construcción del Software.

4. PROGRAMACIÓN ORIENTADA A OBJETOS - POO
CLASES Y MÉTODOS
• Es una unidad de programa que aloja
un tareas que debe realizar esa unidad
ese conjunto de tarea las llamamos
métodos.
• Por ejemplo, una clase que representa
a una cuenta bancaria podría contener
un método para depositar dinero en
una cuenta, otro para retirar dinero de
una cuenta y un tercero para solicitar el
saldo actual de la cuenta.

5. PROGRAMACIÓN ORIENTADA A OBJETOS POO

6. INSTANCIACIÓN Y REUTILIZACIÓN
• Una vez creada la unidad del programa
llamada Clase, se hace necesario utilizarla
para que el programa pueda realizar las
tareas que se definieron.
• Al proceso de hacer esto se le denomina
instanciación. Por lo tanto, un objeto viene
siendo una instancia de su clase.

7. MENSAJES Y LLAMADAS A MÉTODOS
• Cuando usted deposita dinero en una
cuenta bancaria su saldo debe aumentar.
• De manera similar, es posible enviar
mensajes a un objeto.
• Cada mensaje se implementa como
llamada a método, para indicar a un
método del objeto que realice su tarea

8. CLASES Y ATRIBUTOS
• Además de tener capacidades para realizar tareas,
un cuenta también tiene atributos: Cliente, Saldo,
tipo de cuenta, fecha de Apertura, tope de
transacciones en el día, etc. Cada cuenta creada
mantendrá sus propios atributos.
• Cada cliente sabe el saldo de su cuenta, pero no
cuanto hay en la cuenta de otro. De manera similar,
un objeto tiene atributos que lleva consigo a
medida que se utiliza en un programa. Estos
atributos se especifican como parte del objeto de
esa clase
• Los atributos se especifican mediante las variables
de instancia de la clase.

9. ENCAPSULAMIENTO Y OCULTAMIENTO DE
INFORMACIÓN
• Los atributos de mi clase no debería ser
accedidos de manera directa por otra Clase,
deberían acceder a través de un método.
• La manera de proteger el código es creando los
atributos privados y creando un método que
nos permita regular los valores que cada
variable puede tener, escondiendo las variables
para que no se pueda acceder a ellas de
manera directa.
• Esto es el principio básico de encapsulamiento.

10. ENCAPSULAMIENTO Y OCULTAMIENTO DE
INFORMACIÓN

11. HERENCIA
• Mediante la herencia es posible crear con rapidez y de manera conveniente una
nueva clase de objetos.
• La nueva clase (conocida como subclase) comienza con las características de una
clase existente (conocida como superclase), con la posibilidad de personalizarlas y
agregar características únicas propias.

12. MATERIAL DE REFERENCIA
https://docs.microsoft.com/es-es/dotnet/csharp/programming-guide/classes-and-structs/knowing-when-to-use-override-and-new-keywords

13. MATERIAL DE REFERENCIA
https://docs.microsoft.com/es-es/dotnet/csharp/programming-guide/classes-and-structs/knowing-when-to-use-override-and-new-keywords
ABSTRACCIÓN
• Es una clase que no se encuentra
completamente definida. Como no está
completa, no es posible instanciar objetos de
dicha clase.
• Puede contener métodos no-abstractos pero
al menos uno de los métodos debe ser
declarado abstracto.
• Una clase abstracta no se puede instanciar
pero si se puede heredar y las clases hijas
serán las encargadas de agregar la
funcionalidad a los métodos abstractos. Si no
lo hacen así, las clases hijas deben ser
también abstractas.

14. INTERFACE
• Colecciones de métodos relacionados que por lo general nos
permiten indicar a los objetos qué hacer, pero no cómo hacerlo

15. CÓDIGO LIMPIO
Martin, R. (2012) Código Limpio ,Manual de estilo para el desarrollo ágil de software,
Editorial: ANAYA MULTIMEDIA, ISBN: 8441532109
Imagen tomada de Código Limpio Martin R (2012)

16. • La única medida valida de calidad de Código es : WTFs/Minutos.
• vulgarismo inglés, frecuentemente usado para mostrar estupefacción, asombro o
desentendimiento (en ocasiones, desacuerdo), y cuya traducción al castellano podría ser:
«¿Pero qué rayos?», «¿Qué pasó?», «¿Qué diablos?» o «¿Qué demonios?» (o una expresión
similar, algo soez, de todos conocida en España), «¿Pero qué me estás contando?»,
«¿Cómo es la vaina?», «¿Qué onda?,"¡¿Es en serio?!"
Imagen tomada de Código Limpio Martin R (2012)v

17. Bjarne Stoustrup inventor de
C++ y autor de the C++
Programming Language
Me gusta que mi código sea elegante y eficaz
la lógica debe ser directa para evitar errores
ocultos las dependencias deben ser
mínimas para facilitar el mantenimiento, el
procesamiento de errores completo y sujeto a
una estrategia articulada, y el rendimiento
debe ser optimo para que los usuarios no
tiendan a estropear el código con
optimizaciones sin sentido. El código limpio
hace las cosas bien

18. Ward Cunningham Inventor de Wiki, uno de los
Inventores de Programación extreme. Uno de
los impulsores de los patrones de Diseño. Una
de las mentes tras Smalltalk y la POO.
Sabemos que estamos trabajando con
código limpio cuando cada rutina que
leemos resulta ser lo que
esperábamos. Se puede denominar
código atractivo cuando el código hace
que parezca que el lenguaje se ha
creado para el problema en cuestión

19. CONCEPTO DE CÓDIGO LIMPIO
Robert C Martin. “Uncle Bob”
Autor de Clean Code.
Evidentemente no se puede escribir
código si no puede leer el código
circundante.
El código que intente escribir hoy será
más fácil o difícil de escribir en función
de lo fácil o difícil que sea el código
circundante.
.....Si quiere avanzar rápidamente
...haga que su código sea fácil de
escribir y fácil de leer.
Toamdo de https://twitter.com/unclebobmartin

20. Concepto de Código Limpio
Que alguien sepa reconocer una buena
pintura no lo hace un pintor, del mismo
modo reconocer el código limpio no te hace
un buen programador
Para crearlo se requiere miles de técnicas
aplicadas mediante un detallado sentido de
la “Corrección”

21. Somos autores y tendremos Lectores
La próxima vez que escribas código
recuerda que eres un Autor y que
tendrás lectores y escribes para que
tus lectores te juzguen

22. Nombres con sentido
Imagen tomada de Código Limpio Martin R (2012)

23. Usar nombres que revelen las intenciones
• Todo el que lea su código se lo agradecerá.
• Elegir nombres lleva tiempo, pero ahorra trabajo.
• Cámbielo cuando encuentre mejores
• El nombre de una variable función o clase debe: indicar porqué existe,
qué hace y cómo se usa.
• Si un nombre requiere comentario significa que no revela su contenido
int d; // tiempo transcurrido en días
int diasTranscurridos;
int diasDesdeModificacion;
int EdadEnDias;

24. EVITAR LA DESINFORMACIÓN
• Evitar pistas falsas que dificulte el significado del código Evitar
palabras cuyo significado se alejen del que pretendemos.
Public string ListaCuenta; // Grupo de Cuentas
• Evitar nombres con variaciones mínimas. La ortografía similar de
conceptos parecidos es información, el uso de ortografía
incoherente es desinformación:
XYZControladorParaManejoEficientedeCadena
XYZControladorParaAlmacenamientoEficientedeCadena
Imagen tomada de Código Limpio Martin R (2012)

25. Realizar distinciones con sentido
Si el nombre tiene que ser distinto, también debe
tener un significado diferente.
• No usar series de números o pablas
adicionales
Ejemplos:
a1 a2...an.
Name y NameString,
GetCuentaActiva();
GetCuentasActivas();
GetCuentaActivaInfo();
Public Genymdhsd();
• No es incorrecto utilizarlos cuando los
nombres tienen sentido
public static void CopiarChar(char[] a1, char[] a2)
{
for (int i = 0; i < a1.Length; i++)
{
a2[i]=a1[i];
}
}

26. Usar nombres que se puedan pronunciar
class DtaRcrd102
{
private DateTime genymdhms;
private DateTime modymdhms;
private string pszqint;
}
class Cliente
{
private DateTime FechaDeGeneracion;
private DateTime FecahDeModificacion;
readonly private string RegistroId = "102";
}

27. Usar nombres que se puedan Buscar
int diasRealesPorDiaIdeal = 4;
const int DIASDETRABAJOPORSEMANA = 5;
int suma=0;
for (int i = 0; i < NUMERODETAREAS; i++)
{
int diaDeLaTareaReal = TareasEstimadas[i] * diasRealesPorDiaIdeal;
int SemanaDeTareasReales = (diasReales / DIASDETRABAJOPORSEMANA);
suma += SemanaDeTareasReales;
}
int s = 0;
for (int i = 0; i < 15; i++)
{
s += (j[i]*4)/5;
}

28. Usar nombres de dominio de soluciones
Recuerde que el lector de su código será un
programador por lo tanto use nombre,
informáticos, algorítmicos, de patrones,
matemáticos y demás. No conviene extraer todos
los nombres del dominio del problema ya que
no queremos que nuestros colegas pregunten
todo el tiempo por cada termino.

29. Otras Pautas
• Evitar utilizar notación Húngara : int intEdad;
• Evitar utilizar prefijos de miembros
class CCliente
• Opte por la claridad antes que por el entretenimiento
• Nombre para las Clases: debe ser sustantivos,
Ejemplo: Comprador, Vendedor, Cuenta, Banco, Cliente
• Los Métodos deben ser verbos puedes utilizar prefijos
como Get, Set o Is.
Custumer.GetName();
Custumer.SetName(“Andrés”);
PayCheck.IsPosted.
La diferencia entre un programador inteligente y uno profesional, es
que el Profesional sabe que la claridad importa. Martin R. (2008, p. 53)

30. TAMAÑO DE LAS FUNCIONES
• Se sugiere una longitud aproximada de 20 líneas
• Los bloque de instrucciones deben tener una
línea de longitud que por lo regular será una
invocación a otra función, evitar estructuras
anidadas, el nivel de sangrado de una función no
debe ser mayor de dos.
• Las funciones solo deben hacer una cosa, deben
hacerlo bien y debe ser lo único que hagan.
• Argumentos en funciones: lo mejor es cero argumentos, uno (monádico),
dos(diádico), tres (tríadico). Mas de tres(poliádico) requieren una
justificación especial.
• Monádico: Si realiza una pregunta sobre el argumento o si lo procesa lo
trasforma en otra cosa y lo devuelve.
• Poliadica: Es mejor pasar un objeto como argumento.

31. ¿Cómo usar Comentarios en el Código?
Los comentarios no Compensan el código incorrecto
• Comentarios validos:
– Comentarios corporativos
– Aclarativos,
– Advertir una consecuencia
• Comentarios Inválidos
– Comentar cada línea de código
– Comentar Asignación y mención // Escrito por Orlando
– Comentarios de llaves de cierre
– Código Comentado

32. ARQUITECTURA DEL SOFTWARE
Más allá de los algoritmos y estructuras de datos de la computación;
el diseño y la especificación de la estructura general del sistema
emergen como una clase nueva de problema.
Controler
View
Model
Servidor
Cliente
Capa de Presentación
Capa de Reglas de
Negocio
Capa de Datos
Base de Datos
Capa
de
Entidades

33. ¿Qué es la arquitectura de Software?
La respuesta es de varios niveles.
▪ Al más alto nivel son los patrones de
arquitectura que definen la forma y
estructura general del software.
▪ Un nivel inferior es la arquitectura que está
específicamente relacionada con el
propósito de la aplicación de software.
▪ Otro nivel más abajo reside en la
arquitectura de los módulos y sus
interconexiones. Este es el dominio de los
patrones de diseño, paquetes, componentes
y clases.

34. Arquitectura de software
▪ Es la organización o la estructura de los
componentes importantes del sistema que interactúan
mediante interfaces, con componentes compuestos de
interfaces y componentes cada vez más pequeños.
(RUP).
▪ El concepto de más alto nivel de un sistema en su
entorno (IEEE)
▪ Conjunto de patrones que brindan un marco de
referencia necesario para guiar la construcción de un
software. El objetivo es que el equipo de desarrollo
compartan la misma línea de trabajo y puedan cubrir
todos los objetivos y restricciones de la aplicación.
Establecen la estructura, funcionamiento e interacción
entre las partes del software

35. Arquitectura basada en capas
La arquitectura basada en capas se enfoca en
la distribución de roles y responsabilidades de
forma jerárquica proveyendo una forma muy
efectiva de separación de responsabilidades.
• El rol indica el modo y tipo de interacción
con otras capas
• La responsabilidad indica la funcionalidad
que está siendo desarrollada.
https://geeks.ms/jkpelaez/2009/05/30/arquitectura-basada-en-capas/
MATERIAL DE REFERENCIA

36. Arquitectura en capas
• Capa de Presentación o Interfaz de Usuario: esta capa
establece la funcionalidad relacionada con la interfaz de
usuario, esta formada por los formularios y los controles que
se encuentran en los formularios. Es la capa con la que
interactúa el usuario.
• Capa de Negocio: Esta formada por las clases, que
representan objetos que van a ser manejados o utilizados por
toda la aplicación.se encarga del procesamiento de reglas de
negocios
• Capa de Acceso a Datos: en esta capa de establece la
funcionalidad relacionada con el acceso a datos. Contiene
clases que interactúan con la base de datos, éstas clases
altamente especializadas se encuentran en la arquitectura del
sistema y permiten, utilizando los procedimientos
almacenados generados, realizar todas las operaciones con la
base de datos de forma transparente para la capa de negocio.
Capa de Presentación
Capa de Reglas de
Negocio
Capa de Datos
Base de Datos
Servidores

37. Beneficios de la
Arquitectura en Capas
• Mejoras en las posibilidades de mantenimiento. Debido a que
cada capa es independiente de la otra los cambios o
actualizaciones pueden ser realizados sin afectar la aplicación
como un todo.
• Escalabilidad. Como las capas están basadas en diferentes
maquinas, el escalamiento de la aplicación hacia afuera es
razonablemente sencillo.
• Flexibilidad. Como cada capa puede ser manejada y escalada de
forma independiente, la flexibilidad se incrementa.
• Disponibilidad. Las aplicaciones pueden aprovechar la
arquitectura modular de los sistemas habilitados usado
componentes que escalan fácilmente lo que incrementa la
disponibilidad.

38. Problemas de la Arquitectura en Capas
Acoplamiento de Capas.
• La capa de presentación depende
indirectamente de la capa de datos,
cualquier cambio que ocurra en base de
datos tendrá un impacto sobre las capas
superiores.
• La capa de negocio (abstracción) no
debe depender de la de datos (detalle).
Los detalles deben depender de las
abstracciones.
• Este diseño viola el principio SOLID
Dependency Inversion
Servidores
Capa de Presentación
Capa de Reglas de
Negocio
Capa de Datos
Base de Datos
Capa
de
Entidades

39. PROYECTOS DE BIBLIOTECAS DE
CLASES DE ENLACES DINÁMICO PARA
CREAR LAS CAPAS
• Los archivos DLL, siglas por su nombre en inglés Dynamic
Link Library, conocidos en español como Bibliotecas de
Enlaces Dinámicos, consisten en una serie de archivos
que constan de código ejecutable, los cuales hacen
posible la utilización de las aplicaciones que tenemos
instaladas en la PC.
• Algunos programas pueden contener muchos módulos
diferentes, y cada módulo del programa contenido y
distribuido en archivos DLL
• El uso de archivos DLL ayuda a promover el diseño
modular de código, la reutilización de código, uso
eficaz de la memoria y espacio en disco reducido. Por lo
tanto, los programas se cargan más rápido, se ejecutan
más rápidamente y ocupan menos espacio en el disco
del equipo.

40. Referencias
• Martin, R., (2009). Código Limpio: Manual de Estilo para el Desarrollo Ágil de
Software. Pearson Prentice Hall
• Schildt, H., (200) Fundamentos de C# 3.0, McGraw-Hill España, ProQuest Ebook
Central.
• Deitel, L., Deitel, H., (2012) Como programar Java Decima Edición, Pearson Prentice Hall,
ProQuest Ebook Central.