Les pego ese fragmento del libro porque viene al caso y me parece que está bueno (Es cortito).*
Programming to an Interface, not an Implementation* Class inheritance is basically just a mechanism for extending an application's functionality by reusing functionality in parent classes. It lets you define a new kind of object rapidly in terms of an old one. It lets you get new implementations almost for free, inheriting most of what you need from existing classes. However, implementation reuse is only half the story. Inheritance's ability to define families of objects with identical interfaces (usually by inheriting from an abstract class) is also important. Why? Because polymorphism depends on it. When inheritance is used carefully (some will say properly), all classes derived from an abstract class will share its interface. This implies that a subclass merely adds or overrides operations and does not hide operations of the parent class. All subclasses can then respond to the requests in the interface of this abstract class, making them all subtypes of the abstract class. There are two benefits to manipulating objects solely in terms of the interface defined by abstract classes: 1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect. 2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface. This so greatly reduces implementation dependencies between subsystems that it leads to the following principle of reusable object-oriented design: Program to an interface, not an implementation. Don't declare variables to be instances of particular concrete classes. Instead, commit only to an interface defined by an abstract class. You will find this to be a common theme of the design patterns in this book. You have to instantiate concrete classes (that is, specify a particular implementation) somewhere in your system, of course, and the creational patterns (Abstract Factory (87), Builder (97), Factory Method (107), Prototype (117), and Singleton (127) let you do just that. By abstracting the process of object creation, these patterns give you different ways to associate an interface with its implementation transparently at instantiation.Creational patterns ensure that your system is written in terms of interfaces, not implementationsl El 12 de septiembre de 2008 10:53, Gabriel <[EMAIL PROTECTED]> escribió: > GallegO, me parece que se lo que queres decir. A ver si es lo mismo. Lo que > quisiste decir es que el encapsulamiento se pierde desde el lado del > "cliente" de un objeto, es decir, del objeto que colabora con él. Si un > objeto "ajeno" utiliza un protocolo que habla sobre la forma en que fue > implementado el objeto receptor, entonces se estaría perdiendo el > encapsulamiento. Estaría rompiendo el principio que nombra el libro GoF que > decia algo asi como "no programes con implementaciones, programa con > interfaces". > En este caso la herencia seria una cuestión implementativa. Es esto lo que > decias? > > 2008/9/12 GallegO <[EMAIL PROTECTED]> > > >> Andres Valloud escribió: >> > Por favor despues de programar, no antes. >> > >> >> Si jaja, se me ocurrió porque justo ayr un amigo me comento que estaba >> implementando esa métrica con la que nos piensa controlar. Pero despues!!! >> >> Saludos >> GallegO >> > Andres. >> > >> > On Fri, Sep 12, 2008 at 6:30 AM, GallegO <[EMAIL PROTECTED]> wrote: >> > >> >> Andres Valloud escribió: >> >> >> >>> Y, que se yo... no diria que se rompe el encapsulamiento porque por >> >>> definicion las subclases ven la estructura de las instancias de la(s) >> >>> superclases... a mi por lo menos me da mas por el lado de apuntarle un >> >>> dedo acusador al programador mas que a una cosa abstracta como la >> >>> palabra "encapsulamiento" que no se puede defender por si misma y por >> >>> lo tanto no puede tener responsabilidades... >> >>> >> >>> >> >> Exacto! >> >> Hay que controlar(nos) al programador! >> >> >> >> Saludos >> >> GallegO >> >> >> >> >> > >> > > >> > >> > >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
