Hola LopitaL no dispongo de dicha versión de Delphi, olvidé mencionar este hecho. Utilizo Delphi 6.
Nuevamente explico:
Tengo mis clases SujetoFachadaConcreta 1..N (Sujetos concretos que actúan de Fachada), que por por diseño heredan de TAbstractSubject siendo ésta quien implementa la interface IAbstractSubject.
Los Sujetos, no necesariamente van a implementar únicamente esta interface. Es posible de esperar que tengan que implementar otras interfaces que le doten de más comportamiento; como por ejemplo que incluso deba actuar como un Observador de otra. Es decir, visto desde afuera es una fachada Sujeto, pero por dentro además, es un Observador asociado a otro Sujeto.
Es así que hasta se puede hablar de Observadores de Observadores.
Por ejemplo,
Código Delphi
[-]TFacadeUseCase10 = class(TAbstractSubject, IConcreteObserver09);
Este nuevo sujeto fachada es además un observador.
Y no necesariamente de forma comportamiento de forma "recursiva" dentro del contexto de Sujeto/Observador. Sino de otros:
Código Delphi
[-]TFachadeUseCase10 = class(TAbstractSubject, IAdapterModuleContable);
Y así se podría continuar... No existe una relación 1-1 explícita en lo que hace a clases e interface, por tanto la respuesta es No se puede dar el caso de que exista una única clase implemente una única interface. Es más, si lo vemos en términos abstractos todos, y cualesquiera, de los Sujetos heredados de TAbstractSubject están implementando indirectamente la interface IAbstractSubject. El único lugar en donde tiene lugar la interpretación 1-1 es para TAbstractSubject e IAbstractSubject ¡No hay, ni tiene sentido que otras clases implementen esta interface! ¡Que es la que hace de base para todos los sujetos!
Entonces por cada Fachada o mejor dicho Sujeto concreto existe una interface que hereda de IAbstractObserver, aquí si se podría entender cierta relación 1-1 entre clase Sujeto e interface.
Cada Sujeto tiene un contrato con una interface Observer concreta (esa es la idea, el sujeto no va a publicar cosas ajenas a su comportamiento y diseño... es como decir que un SujetoVenta tenga posibilidad de notificar cosas relacionados con los Pagos). Esta interface concreta dispone de los métodos y eventos que cualquier Observador deberá implementar. El punto es que NINGUN Sujeto concreto implementa estas interfaces observer concretas, más bien las registra en su lista, y les notifica a cualquier objeto observador que las implemente. Son los múltiples Observadores que darán respuesta a esta interface.
Por ello es que no existe una relación 1-1 entre la interface Observer y alguna clase que actúe de Observer. Pueden, y se darán casos, en que una clase cualquiera sea Observador de más de una interface:
Código Delphi
[-]TConcreteObserver19 = class(TinterfacedObject, IConcreteObserver10, IConcreteObserver09);
Para el ejemplo, este observador está interesado en las respuestas que provengan, de TConcreteSubject10, y TConcreteSubject09; si respetásemos las convenciones de nombramiento.
Espero que con ello se entienda que en realidad no necesariamente existe una única clase que implemente una interface, salvo puntualmente para TAbstractSubject e IAbstractSubject.
Ahora bien, no todo Sujeto actúa de Fachada (que es otro patrón ni una extensión a patrón Observer); ni necesariamente a la inversa Toda Fachada es un Sujeto aunque por lo habitualmente es de esperar.
Además, no todo Sujeto y/o Fachada será Singleton; pero por lo general las Fachadas si se comportan como Singleton.
Singleton es otro patrón... que lo único que indica es que se redefina los contructores virtuales de clase para garantizar de que se cree una única instancia. De modo que ante cualquier otro intento de crear se regrese ésta.
Aquí es donde surje el problema. Tengo tanto sujetos concretos como fachadas sujetos que serán singletons, como otras que no lo serán (también se pueden encontrar clases NO sujetos y que sean Singleton). Mi pregunta es ¿Cómo dotar a las clases adecuadas de un comportamiento Singleton cuando ésta hereda e implementa alguna interfaz? Para el caso que se está analizando aquí: observa que TAbstractSubject ya viene con un constructor y destructor, y la idea es que el concepto de un Singleton no se propague a este nivel y termine resultando en que una única clase cualquiera hija y no se creen el resto... es decir debo tener tanto mis Sujetos singleton como mis sujetos no singletons sin que afecte a TAbstractSubject. De allí que mi idea es
definir a cada sujeto concreto si será o no un singleton.
El peligro y mi confusión está en que no se trata de simples sujetos sino que éstos implementan interfaces y cuando se utilizan éstas las clases y los recursos no se liberan sino es hasta tener un conteo de referencia igual a cero (no hay clase, sea del tipo que sea, que la implemente creada). Por tanto... en un esquema de interfaces no se habla de singleton ni ¡se esperan interface singleton! Son los objetos, de ciertas clases particulares que serán singleton.
¿Se me entiende ahora?
