Código 418

Introducción El diseño de una solución software basado en objetos requiere que los objetos se relacionen entre sí. Cuando una clase necesita utilizar el código de otra clase necesitamos relacionar estas dos clases. Esta relación la podemos establecer de varias formas y dos de las más importantes en POO son: heredando de una clase base: el objeto adquiere todas las propiedades y comportamientos del objeto base; por composición: conteniendo instancias de otros objetos que implementen esa funcionalidad. Un principio de diseño en POO dice que ante la posibilidad de resolver un problema con cualquiera de estas dos soluciones deberíamos "favorecer" la composición sobre la herencia . Hay que remarcar que la palabra "favorecer" sólo significa eso: "favorecer". No se trata de una imposición. Más bien es una recomendación cuando ambas posibilidades son aplicables. Existen muchos escenarios en los que nos encontraremos en que las dos soluciones son fácilmente ...

Encapsular constructores Hay un principio de programación que dice: separar el uso de las clases de su creación . De la misma forma que anteriormente he mencionado que para acceder al estado de una clase se debe controlar la forma en que lo vamos a permitir por medio de los controladores de acceso, también se puede hacer extensible a su construcción. Podemos encontrarnos en situaciones en las que el hecho de crear una instancia de una clase puede conllevar conocimientos internos que no tiene por qué conocer el cliente. Para llevar a cabo esta práctica se protege el constructor mediante un modificador private o protected evitando la posibilidad de crear una instancia desde el exterior. La única forma de crear una instancia es mediante el uso de uno o varios métodos estáticos de la propia clase. En el siguiente ejemplo estamos restringiendo la creación de un objeto Coche . Sólo se pueden crear mediante los métodos estáticos. Así conseguimos que la lógica de creación de objetos ...

Descriptores de acceso. Controlando la forma de acceder al estado. Que una clase permita leer un valor a otra clase que lo requiera no quiere decir que lo pueda modificar. Y si una clase debe poder modificarlo no significa tampoco que lo pueda hacer de forma directa, sino que quizás debería utilizar descriptores de acceso (assessors) , también llamados getters and setters o propiedades en .Net. Usar propiedades es una buena práctica incluso cuando el acceso es directo, es decir, aunque lo único que hagamos sea devolver un valor en el get o asignar un valor en el set. Quién sabe si en un futuro vamos a necesitar un descriptor de acceso con implementación. En este caso sólo tendríamos que implementar la lógica en el get o en el set sin alterar la compatibilidad binaria. Para explicarlo mejor vamos a ver un ejemplo simple del uso de un descriptor de acceso. Manos a la obra Imaginemos que tenemos el campo precio que nos guarda un valor de una cantidad de dinero. Si optamos por hacer...

Un ejemplo de encapsulamiento en la vida real Supongamos un taller de carpintería que fabrica muebles a medida. Por una parte tendríamos el propio taller, que sería la clase a encapsular. Por otra los clientes, que serían nuestros usuarios y representarían las clases que USAN la clase taller. Y por otra parte podríamos pensar en talleres filiales que representarían una especialización del taller matriz, es decir, clases que extienden al taller de carpintería y por lo tanto SON talleres. El taller cuenta con funcionalidades puestas al servicio de los clientes como la elaboración de presupuestos, consulta de catálogos, selección de tipo de madera, selección de color, etc. También cuenta con funcionalidades propias del taller como cortar, lijar, pintar, barnizar, ensamblar mueble, etc. Para la elaboración de los presupuestos el taller matriz cuenta con una tarifa de precios que sólo los talleres pueden acceder para poder elaborar los presupuestos. Esta tarifa la fija el taller mat...

Introducción En programación orientada a objetos el término encapsulamiento es utilizado indistintamente para describir dos conceptos diferentes pero a la vez relacionados entre sí: Como mecanismo de restricción del acceso a componentes de un objeto; Como construcción del lenguaje para facilitar el “empaquetado” del estado y el comportamiento. En este post el significado al que se hace referencia es al primero de ellos. La visibilidad o accesibilidad es el primer paradigma que nos encontramos al empezar a escribir nuestro código. Cuando comenzamos a escribir una clase, interfaz, enumerado o estructura, lo primero que hacemos es establecer su modificador de acceso, y si no lo hacemos, se establecerá el modificador por defecto. Lo mismo ocurre cuando empezamos a escribir cada uno de sus miembros: variables de estado (campos) y métodos: lo primero de todo es escribir su modificador de acceso. A menudo me encuentro con código sin tener en cuenta este aspecto: código demasiado “ab...