jueves, 9 de febrero de 2017

Profesor de Stanford asegura que si eliminas estas dos frases de tu vocabulario tendrás más éxito

La forma de hablar y las palabras que una persona usa no solo afectan la forma en la que los demás la perciben, sino que también tienen el potencial para incidir en su comportamiento, señala un profesor de Stanford.

 
Cambiar una palabra por otra podría ayudarte a lograr tus objetivos.

  Así lo asegura Bernard Roth, profesor de ingeniería de la Universidad Stanford y director académico del Instituto de Diseño Hasso Plattner de Stanford, el d.school.

  En su nuevo libro, The Achievement Habit, Roth sugiere algunos cambios lingüísticos que pueden ayudarte a tener más éxito. He aquí los dos más sencillos:

1. Cambia ‘pero’ por ‘y

  Es probable que en alguna ocasión te sientas tentado a decir: “quiero ir al cine, pero tengo que trabajar”.

  En su lugar, Roth sugiere que digas: “quiero ir al cine, y tengo que trabajar”.

  Escribió: “Cuando utilizas la palabra pero creas un conflicto, a veces una razón, que en realidad no existe”. En otras palabras, es posible ir al cine y también hacer tu trabajo, solo tienes que encontrar una solución.

  En cambio, cuando utilizas la palabra y, “estás obligando a tu cerebro a procesar ambas partes de la frase”, explicó Roth. Quizá veas una película más corta o tal vez delegues parte de tu trabajo.

2. Cambia ‘tengo que hacer’ por ‘quiero hacer

 Roth recomienda un ejercicio sencillo: la próxima vez que pienses ‘tengo que’, cambia tengo por quiero.

 “Este ejercicio es muy efectivo para que las personas tomen consciencia de que lo que hacen en su vida, incluso las cosas que encuentran desagradables, es porque lo han elegido”, comentó.

 Por ejemplo, uno de los estudiantes de Roth sintió que tenía que matricularse en los cursos de matemáticas que requería su programa de posgrado, a pesar de que los odiaba. Después de terminar el ejercicio, se percató que realmente quería tomar las clases ya que el beneficio de completar los cursos era mayor que la incomodidad de asistir a las clases que no disfrutaba.

 Ambos cambios se basan en un componente clave de la estrategia de resolución de problemas llamada pensamiento de diseño. Cuando utilizas esta estrategia, desafías a tu forma automática de pensar y puedes percibir las cosas como realmente son.

Cuando utilizas un lenguaje diferente puedes percatarte de que un problema no es tan difícil de resolver como parece y que tienes más control sobre tu vida de lo que realmente crees.

miércoles, 8 de febrero de 2017

12 trampas financieras que debes evitar ¿Quieres ser rico? Tienes que pensar como millonario y olvidar los clichés que las clases bajas tienen sobre el dinero.

La mayoría de las personas que crecimos en las clases bajas y medias pasamos el resto de nuestras vidas combatiendo pensamientos propios de la gente pobre. Si fuiste educado como yo, por padres que tenían las mejores intenciones pero pocas ideas para lograr estabilidad económica, entonces hay una probabilidad grande de que tengas que evitar trampas mentales financieras todo el tiempo.
Nadie puede negar que las personas opulentas operan y piensan de manera diferente sobre el dinero, la riqueza, las finanzas y las inversiones. Aquí hay algunos "clichés financeros" que ellos evitan:
1. “Sólo quiero tener suficiente dinero para vivir bien”
En la clase media existe la idea de que se puede alcanzar una especie de lugar confort básico, un concepto que puede limitar cualquier libertad financiera. Considera que un número importante de personas ahorra muy poco dinero para el retiro. Esto ha hecho que miles de trabajadores sean incapaces de retirarse de verdad al llegar la edad de la jubilación ya que en ese momento carecen del dinero necesario para cubrir sus gastos.
2. “Necesito hacer dinero”
Hacer dinero, literalmente, es ilegal. Esta idea de que “hay que hacer dinero” para tenerlo te limita a creer que tienes que cambiar tu tiempo por efectivo. Deja de pensar en el dinero como algo que tienes que fabricar y empieza a verlo como algo que puedes “coleccionar”. Es simple, cuando intercambias algo de valor con el público, obtienes dinero.
3. “Más grande no siempre es mejor”
Error. Deja de pensar en pequeño. Las mejores compañías del mundo son enormes. Aunque no lo creas, ser pequeño te roba mucha energía.  En los últimos 12 meses he entrevistado a más de 50 emprendedores muy exitosos que manejan compañías de hasta 100 millones de dólares y que empezaron con nada. Casi todos coincidieron en que su mayor arrepentimiento era no haberse atrevido a pensar en grande desde el principio.
4. “Más dinero, más problemas”
Esta es una idea que las personas sin dinero utilizan para justificar su falta de riqueza. Si tener más dinero trae más problemas, entonces ¡que vengan los problemas! Ya fui pobre una vez y eso sí era una situación difícil. Hay que dejar de hacer que la riqueza sea fea. No lo es.
La verdad es que entre más dinero tengas, más control tienes sobre las elecciones que haces en cada aspecto de tu vida. Por ejemplo, si compras un boleto de avión de primera clase sabes que no tendrás que viajar incómodo al lado de una persona escandalosa. Tener tu propio jet significa poseer total libertad para viajar, pero también pagar el salario de dos pilotos, un mecánico y el mantenimiento del avión. Tener más dinero no significa tener más problemas, sólo NUEVOS problemas.   
5. “Se necesita dinero para hacer dinero”
La realidad es que más de tres cuartos de todos los millonarios del mundo formaron su propia riqueza. Eso significa que personas ordinarias se volvieron ricas porque tuvieron el valor de seguir sus sueños.
La frase “se necesita dinero para hacer dinero” es completamente falsa.  Aunque los millonarios usan su dinero para invertir y así generar riqueza, lo cierto es que al principio lo que se requiere es persistencia. La idea de que absolutamente se necesita tener dinero para empezar a generar dinero hace que te encasilles y te vuelvas complaciente.
6. “El dinero no crece en los árboles”
La persona que usa esta frase sugiere que el dinero es limitado y escaso. En realidad hay trillones y trillones de dólares en el planeta. La única falta real de dinero es la que está presente en la mente de quienes no lo tienen y no saben cómo generarlo.
7. “Un día más, un peso más”
La fuerza laboral del mundo intercambia tiempo por dinero todos los días. ¿Tu tiempo vale 10 pesos o 500 pesos la hora? La realidad es que no importa cuánto ganes, sigues vendiendo tu tiempo y ese es un recurso limitado.
Los ricos intercambian pesos por tiempo porque saben que es más valioso que el dinero. Las personas promedio creen que la única manera de tener más dinero es trabajar más horas.
8. “El dinero es la raíz de todos los males”
El dicho original dice “El amor al dinero es la raíz de todos los males”. La frase se ha desvirtuado para mostrar al dinero como algo malo. Creo que es malo no poder alimentar a mi familia, ayudar en mi iglesia, apoyar a los comercios de mi comunidad, dar empleos con mis empresas y no perseguir mis sueños.
Bill Gates alguna vez dijo: “Si naciste pobre, no es tu culpa. Si mueres pobre, sí lo es”.
9. “Un centavo ahorrado, es un centavo ganado”
Si crees en esto jamás tendrás libertad financiera. Un centavo ahorrado sigue siendo sólo un centavo y si pasas tu vida pensando en centavos jamás lograrás formar una riqueza. Ahorrar no es malo, pero en general la gente no piensa en poner su dinero a trabajar. Nadie se hizo rico sólo ahorrando. Nadie.
10. “El dinero no compra la felicidad” 
La verdad es que nunca he conocido a una persona rica que hubiera tenido que elegir entre felicidad y fortuna. Ambos conceptos son totalmente independientes.
Conozco personas felices e infelices. Mi esposa es la persona más feliz del planeta y siempre lo ha sido, sin importar cuánto dinero tenga. Les aseguro que le gusta tener la libertad de gastar dinero en nuestra familia sin tener que preocuparse constantemente. No hay manera en que el dinero te pueda hacer feliz o infeliz- es sólo dinero.
Si eres una persona miserable, entonces serás una persona miserable con o sin dinero.  
11. “Una moneda por tus pensamientos”
Este dicho muestra cuán barato las personas consideran que es su tiempo. Yo poseo cuatro negocios y todos empezaron con simples ideas que decidí perseguir. El hombre que creó el velcro, el fundador de Starbucks, Henry Ford y demás figuras de su tipo tuvieron grandes pensamientos y no los cambiaron por simples monedas.
Deja de pensar que tus ideas valen meros centavos.
12. “Las personas ricas son egoístas”
Voy a ser honesto. He sido egoísta en mi vida para no tener que depender económicamente de alguien. Mi papá murió cuando yo tenía 10 años y mi mamá tuvo que arreglárselas para mantener y darles educación a tres hijos. Tenía que ser un poco egoísta para que sus niños pudieran comer.  
Se necesita ser un poco de egoísmo y autoestima para que cuidar de ti mismo y de los tuyos sea una prioridad para que no te conviertas en el problema de otra persona. Si no piensas lo suficientemente alto de tus propias finanzas, jamás podrás tomar las decisiones difíciles y necesarias para cuidar de tu pareja, hijos, comunidad y futuro.
Es mejor ser un poco egoísta para lograr tener algo qué compartir, ya sea oportunidades, dinero o experiencia. Estoy harto de las personas que dicen “si yo tuviera el dinero de Bill Gates ayudaría a muchas personas” pero en la vida diaria jamás pueden ayudar a las personas porque no cuidan sus propias finanzas.  
Cualquier millonario te dirá que toda persona se puede volver rica. Elimina de tu mente las trampas financieras y empieza a pensar con libertad.

martes, 24 de enero de 2017

INYECCION DE DEPENDENCIAS

I found this funny example in terms of loose coupling:
Any application is composed of many objects that collaborate with each other to perform some useful stuff. Traditionally each object is responsible for obtaining its own references to the dependent objects (dependencies) it collaborate with. This leads to highly coupled classes and hard-to-test code.
For example, consider a Car object.
Car depends on wheels, engine, fuel, battery, etc. to run. Traditionally we define the brand of such dependent objects along with the definition of the Car object.
Without Dependency Injection (DI):
class Car{
  private Wheel wh= new NepaliRubberWheel();
  private Battery bt= new ExcideBattery();

  //The rest
}
Here, the Car object is responsible for creating the dependent objects.
What if we want to change the type of its dependent object - say Wheel - after the initial NepaliRubberWheel() punctures? We need to recreate the Car object with its new dependency say ChineseRubberWheel(), but only the Car manufacturer can do that.
Then what does the Dependency Injection do us for...?
When using dependency injection, objects are given their dependencies at run time rather than compile time (car manufacturing time). So that we can now change the Wheel whenever we want. Here, the dependency (wheel) can be injected into Car at run time.
After using dependency injection:
Here, we are injecting the dependencies (Wheel and Battery) at runtime. Hence the term : Dependency Injection.
class Car{
  private Wheel wh= [Inject an Instance of Wheel (dependency of car) at runtime]
  private Battery bt= [Inject an Instance of Battery (dependency of car) at runtime]
  Car(Wheel wh,Battery bt) {
      this.wh = wh;
      this.bt = bt;
  }
  //Or we can have setters
  void setWheel(Wheel wh) {
      this.wh = wh;
  }
}




Inyección de dependencias
En informáticainyección de dependencias (en inglés Dependency Injection, DI) es un patrón de diseño orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. El término fue acuñado por primera vez por Martin Fowler.
Historia[editar]
En los comienzos de la programación, los programas eran lineales y monolíticos. El flujo de ejecución era simple y predecible, ejecutándose línea tras línea.
Aparecieron dos conceptos para estructurar el código: la modularidad y la reutilización de los componentes: se crean bibliotecas de componentes reutilizables. El flujo se complica, saltando de componente a componente, y aparece un nuevo problema: la dependencia (acoplamiento) entre los componentes.
El problema de la dependencia se empieza a considerar lo suficientemente importante como para definir nuevos conceptos en el diseño :
·         Inversión de control (IoC).
·         Inyección de Dependencias (DI), que es una forma de inversión de control.
Implementación del patrón en Java[editar]
La forma habitual de implementar este patrón es mediante un "Contenedor DI" y objetos planos o simples por ejemplo los llamados POJO en java. El contenedor inyecta a cada objeto los objetos necesarios según las relaciones plasmadas en un fichero de configuración.
Típicamente este contenedor es implementado por un framework externo a la aplicación (como Spring entre otros), por lo cual en la aplicación también se utilizará inversión de control al ser el contenedor (almacenado en una biblioteca) quien invoque el código de la aplicación. Ésta es la razón por la que los términos de inversión de control e inyección de dependencias se confunden habitualmente entre sí.
Ilustración de código usando Java[editar]
El siguiente ejemplo muestra una implementación sin inyección de dependencias.
public class Vehiculo {

    private Motor motor = new Motor();
   
    /** @retorna la velocidad del vehículo*/
    public Double enAceleracionDePedal(int presionDePedal) {
        motor.setPresionDePedal(presionDePedal);
        int torque = motor.getTorque();
        Double velocidad = ... //realiza el cálculo
        return velocidad;
    }

}

//se omite la clase Motor ya que no es relevante para este ejemplo
La implementación de arriba necesita crear una instancia de Motor para calcular su velocidad. El siguiente ejemplo sencillo muestra una implementación usando inyección de dependencias.
public class Vehiculo {

    private Motor motor = null;
   
    public void setMotor(Motor motor){
        this.motor = motor;
    }

    /** @retorna la velocidad del vehículo*/
    public Double enAceleracionDePedal(int presionDePedal) {
        Double velocidad = null;
        if (null != motor){
            motor.setPresionDePedal(presionDePedal);
            int torque = motor.getTorque();
            velocidad = ... //realiza el cálculo
        }  
        return velocidad;
    }
}

//se omite la clase Motor ya que no es relevante para este ejemplo

public class VehiculoFactory {

    public Vehiculo construyeVehiculo() {
        Vehiculo vehiculo = new Vehiculo();
        Motor motor = new Motor();
        vehiculo.setMotor(motor);
        return vehiculo;
    }

}
En este ejemplo VehiculoFactory representa al proveedor. Es una aplicación sencilla del patrón de diseño fábrica que hace posible que la clase Vehículo no requiera saber cómo obtener un motor por sí misma, sino que es la responsabilidad de VehiculoFactory.




Basically, instead of having your objects creating a dependency or asking a factory object to make one for them, you pass the needed dependencies in to the constructor or via property setters, and you make it somebody else's problem (an object further up the dependency graph, or a dependency injector that builds the dependency graph). A dependency as I'm using it here is any other object the current object needs to hold a reference to.
One of the major advantages of dependency injection is that it can make testing lots easier. Suppose you have an object which in its constructor does something like:
public SomeClass() {
    myObject = Factory.getObject();
}
This can be troublesome when all you want to do is run some unit tests on SomeClass, especially if myObject is something that does complex disk or network access. So now you're looking at mocking myObject but also somehow intercepting the factory call. Hard. Instead, pass the object in as an argument to the constructor. Now you've moved the problem elsewhere, but testing can become lots easier. Just make a dummy myObject and pass that in. The constructor would now look a bit like:
public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}
Most people can probably work out the other problems that might arise when not using dependency injection while testing (like classes that do too much work in their constructors etc.) Most of this is stuff I picked up on the Google Testing Blog, to be perfectly honest...


The best definition I found so far is one by James Shore:
"Dependency Injection" is a 25-dollar term for a 5-cent concept. [...] Dependency injection means giving an object its instance variables. [...].
There is an article by Martin Fowler that may prove useful too.
Dependency injection is basically providing the objects that an object needs (its dependencies) instead of having it construct them itself. It's a very useful technique for testing, since it allows dependencies to be mocked or stubbed out.
Dependencies can be injected into objects by many means (such as constructor injection or setter injection). One can even use specialized dependency injection frameworks (e.g Spring) to do that, but they certainly aren't required. You don't need those frameworks to have dependency injection. Instantiating and passing objects (dependencies) explicitly is just as good an injection as injection by framework.

Dependency injection separates the creation of a client's dependencies from the client's behavior, which allows program designs to be loosely coupled[7] and to follow the dependency inversion and single responsibility principles.[4][8] It directly contrasts with the service locator pattern, which allows clients to know about the system they use to find dependencies.
An injection, the basic unit of dependency injection, is not a new or a custom mechanism. It works in the same way that "parameter passing" works.[9] Referring to "parameter passing" as an injection carries the added implication that it's being done to isolate the client from details.
An injection is also about what is in control of the passing (never the client) and is independent of how the passing is accomplished, whether by passing a reference or a value.
Dependency injection involves four roles:
·         the service object(s) to be used
·         the client object that is depending on the services it uses
·         the interfaces that define how the client may use the services
·         the injector, which is responsible for constructing the services and injecting them into the client
Any object that may be used can be considered a service. Any object that uses other objects can be considered a client. The names have nothing to do with what the objects are for and everything to do with the role the objects play in any one injection.
The interfaces are the types the client expects its dependencies to be. At issue is what they make accessible. They may truly be interface types implemented by the services but also may be abstract classes or even the concrete services themselves, though this last would violate DIP[10] and sacrifice the dynamic decoupling that enables testing. It's only required that the client does not know which they are and therefore never treats them as concrete, say by constructing or extending them.
The client should have no concrete knowledge of the specific implementation of its dependencies. It should only know the interface's name and API. As a result, the client won't need to change even if what is behind the interface changes. However, if the interface is refactored from being a class to an interface type (or vice versa) the client will need to be recompiled.[11] This is significant if the client and services are published separately. This unfortunate coupling is one that dependency injection cannot resolve.
The injector introduces the services into the client. Often, it also constructs the client. An injector may connect together a very complex object graph by treating an object like a client and later as a service for another client. The injector may actually be many objects working together but may not be the client. The injector may be referred to by other names such as: assembler, provider, container, factory, builder, spring, construction code, or main.
Dependency injection can be applied as a discipline, one that asks that all objects separate construction and behavior. Relying on a DI framework to perform construction can lead to forbidding the use of the new keyword, or, less strictly, only allow direct construction of value objects.[12][13][14][15]

Taxonomy[edit]

Inversion of control (IoC) is more general than DI. Put simply, IoC means letting other code call you rather than insisting on doing the calling. An example of IoC without DI is the template method pattern. Here polymorphism is achieved through subclassing, that is, inheritance.[16]
Dependency injection implements IoC through composition so is often identical to that of the strategy pattern, but while the strategy pattern is intended for dependencies to be interchangeable throughout an object's lifetime, in dependency injection it may be that only a single instance of a dependency is used.[17] This still achieves polymorphism, but through delegation and composition.

Dependency injection frameworks[edit]

Application frameworks such as Spring, Guice, Play framework, Salta, Glassfish HK2, and Managed Extensibility Framework (MEF) support dependency injection but are not required to do dependency injection.[18][19]

Advantages[edit]

·         Dependency injection allows a client the flexibility of being configurable. Only the client's behavior is fixed. The client may act on anything that supports the intrinsic interface the client expects.
·         Dependency injection can be used to externalize a system's configuration details into configuration files allowing the system to be reconfigured without recompilation. Separate configurations can be written for different situations that require different implementations of components. This includes, but is not limited to, testing.
·         Because dependency injection doesn't require any change in code behavior it can be applied to legacy code as a refactoring. The result is clients that are more independent and that are easier to unit test in isolation using stubs or mock objects that simulate other objects not under test. This ease of testing is often the first benefit noticed when using dependency injection.
·         Dependency injection allows a client to remove all knowledge of a concrete implementation that it needs to use. This helps isolate the client from the impact of design changes and defects. It promotes reusability, testability and maintainability.[20]
·         Reduction of boilerplate code in the application objects, since all work to initialize or set up dependencies is handled by a provider component.[20]
·         Dependency injection allows concurrent or independent development. Two developers can independently develop classes that use each other, while only needing to know the interface the classes will communicate through. Plugins are often developed by third party shops that never even talk to the developers who created the product that uses the plugins.
·         Dependency Injection decreases coupling between a class and its dependency.[21][22]

Disadvantages[edit]

·         Dependency injection creates clients that demand configuration details be supplied by construction code. This can be onerous when obvious defaults are available.
·         Dependency injection can make code difficult to trace (read) because it separates behavior from construction. This means developers must refer to more files to follow how a system performs.
·         Dependency injection typically requires more upfront development effort since one can not summon into being something right when and where it is needed but must ask that it be injected and then ensure that it has been injected.
·         Dependency injection can cause an explosion of types, especially in languages that have explicit interface types, like Java and C# [23]
·         Dependency injection forces complexity to move out of classes and into the linkages between classes which might not always be desirable or easily managed.[24]
·         Ironically, dependency injection can encourage dependence on a dependency injection framework.[24][25][26]

Examples[edit]

Without dependency injection[edit]

In the following Java example, the Client class contains a Service member variable that is initialized by the Client constructor. The client controls which implementation of service is used and controls its construction. In this situation, the client is said to have a hard-coded dependency on ServiceExample.
// An example without dependency injection
public class Client {
    // Internal reference to the service used by this client
    private ServiceExample service;
 
    // Constructor
    Client() {
        // Specify a specific implementation in the constructor instead of using dependency injection
        service = new ServiceExample();
    }
 
    // Method within this client that uses the services
    public String greet() {
        return "Hello " + service.getName();
    }
}
Dependency injection is an alternative technique to initialize the member variable rather than explicitly creating a service object as shown above.

Three types of dependency injection[edit]

There are at least three ways an object can receive a reference to an external module:[27]
·         constructor injection: the dependencies are provided through a class constructor.
·         setter injection: the client exposes a setter method that the injector uses to inject the dependency.
·         interface injection: the dependency provides an injector method that will inject the dependency into any client passed to it. Clients must implement an interface that exposes a setter method that accepts the dependency.

Other types[edit]

It is possible for DI frameworks to have other types of injection beyond those presented above.[28]
Testing frameworks may also use other types. Some modern testing frameworks do not even require that clients actively accept dependency injection thus making legacy code testable. In particular, in the Java language it is possible to use reflection to make private attributes public when testing and thus accept injections by assignment.[29]
Some attempts at Inversion of Control do not provide full removal of dependency but instead simply substitute one form of dependency for another. As a rule of thumb, if a programmer can look at nothing but the client code and tell what framework is being used, then the client has a hard-coded dependency on the framework.

Constructor injection[edit]

This method requires the client to provide a parameter in a constructor for the dependency.
// Constructor
Client(Service service) {
    // Save the reference to the passed-in service inside this client
    this.service = service;
}

Setter injection[edit]

This method requires the client to provide a setter method for the dependency.
// Setter method
public void setService(Service service) {
    // Save the reference to the passed-in service inside this client
    this.service = service;
}

Interface injection[edit]

This is simply the client publishing a role interface to the setter methods of the client's dependencies. It can be used to establish how the injector should talk to the client when injecting dependencies.
// Service setter interface.
public interface ServiceSetter {
    public void setService(Service service);
}
 
// Client class
public class Client implements ServiceSetter {
    // Internal reference to the service used by this client.
    private Service service;
 
    // Set the service that this client is to use.
    @Override
    public void setService(Service service) {
        this.service = service;
    }
}

Constructor injection comparison[edit]

Preferred when all dependencies can be constructed first because it can be used to ensure the client object is always in a valid state, as opposed to having some of its dependency references be null (not be set). However, on its own, it lacks the flexibility to have its dependencies changed later. This can be a first step towards making the client immutable and therefore thread safe.
// Constructor
Client(Service service, Service otherService) {
    if (service == null) {
        throw new InvalidParameterException("service must not be null");
    }
    if (otherService == null) {
        throw new InvalidParameterException("otherService must not be null");
    }
 
    // Save the service references inside this client
    this.service = service;
    this.otherService = otherService;
}

Setter injection comparison[edit]

Requires the client to provide a setter method for each dependency. This gives the freedom to manipulate the state of the dependency references at any time. This offers flexibility, but if there is more than one dependency to be injected, it is difficult for the client to ensure that all dependencies are injected before the client could be provided for use.
// Set the service to be used by this client
public void setService(Service service) {
    if (service == null) {
        throw new InvalidParameterException("service must not be null");
    }
    this.service = service;
}
 
// Set the other service to be used by this client
public void setOtherService(Service otherService) {
    if (otherService == null) {
        throw new InvalidParameterException("otherService must not be null");
    }
    this.otherService = otherService;
}
Because these injections happen independently there is no way to tell when the injector is finished wiring the client. A dependency can be left null simply by the injector failing to call its setter. This forces the check that injection was completed from when the client is assembled to whenever it is used.
// Set the service to be used by this client
public void setService(Service service) {
    this.service = service;
}
 
// Set the other service to be used by this client
public void setOtherService(Service otherService) {
    this.otherService = otherService;
}
 
// Check the service references of this client
private void validateState() {
    if (service == null) {
        throw new IllegalStateException("service must not be null");
    }
    if (otherService == null) {
        throw new IllegalStateException("otherService must not be null");
    }
}
 
// Method that uses the service references
public void doSomething() {
    validateState();
    service.doYourThing();
    otherService.doYourThing();
}


Blogger Widgets