2011-08-30 9 views
5

Estoy teniendo una duda con las creaciones de métodos en una clase para configurar la información.Forma preferida de declarar métodos en una clase

  1. la creación de métodos separados para ajustar cada atributo

    class Address{ 
        private String name; 
        private String city; 
    
        public setName(String name) { ... } 
        public setCity(String name) { ... } 
    } 
    
  2. la creación de un método único para el establecimiento de todos los atributos

    class Address{ 
        private String name; 
        private String city; 
    
        public setAddress(String name,String city) { ... } 
    } 
    

desde arriba de dos maneras que es preferible en el punto de memoria ¿ver?

+2

Muéstranos lo que quieres decir con ejemplos de código para ambos enfoques. –

+0

¿Cuál es el propósito de esta clase? ¿es un objeto de valor? ¿requerirá establecer cada valor de forma independiente? ¿Estos valores tienen que cambiar después de la creación del objeto? ¿Qué quiere decir con "punto de vista de la memoria"? Memoria humana o memoria de la computadora? – buritos

+0

primer ejemplo está bien, segundo ejemplo es malo. Usa un constructor – BalusC

Respuesta

1

Esta no es una pregunta clara. ¿Quiere decir que preferiría tener dos métodos, como setFoo(String) y setBar(int), o un método como setFooBar(String, int)? Realmente depende de si estas son propiedades lógicamente diferentes, en cuyo caso desea métodos individuales, o si a menudo (o solo) tiene sentido establecerlos juntos. Usted podría proporcionar ambos.

Ni tiene ningún impacto en la memoria, no.

3

No veo cómo los dos enfoques podrían ser diferentes en cuanto a la memoria.

Elija el enfoque que tenga más sentido tener en la interfaz de la clase.

Recomendaría ir con el acercamiento 2 solo si ambas propiedades están lógicamente relacionadas, o si hay alguna clase invariante que no desea romper temporalmente (incluso temporalmente).

En su ejemplo Address, definitivamente iría con dos métodos setter, ya que cuando se habla de direcciones, el nombre y la ciudad no tienen ninguna relación.


Para métodos en general Yo diría que si usted divide un método en dos tiene poco efecto sobre el consumo de memoria. Cada objeto no obtiene su propio conjunto de métodos asignados. La memoria que contiene los métodos se comparte entre todas las instancias de una clase.


Regla de oro: empeño es hacer de interfaz de su clase limpia y lógica.

0

Generalmente, escribe un método setter y un método getter para cada atributo.

Realmente no veo el caso cuando un método es suficiente para configurar todos los atributos. En este caso, ¿todos los atributos deberían tener el mismo valor? O siempre tendrías que pasar parámetros para todos los atributos. Ambos casos no son realmente lo que quieres. Entonces, debes preferir claramente tu primer acercamiento.

2

Por qué no usar el método # 2

Su segundo ejemplo no es recomendable porque si se ha añadido un nuevo campo a la clase de direcciones, a continuación, se puede añadir que en el método de selección existente o se crea una nuevo método setter? Si lo agrega al método setter existente, cualquier clase que invoque ese método se romperá.Y si creó un nuevo método setter, entonces es confuso para cualquiera que quiera usar esa clase por qué ciertos campos se agrupan de esa manera mientras que otros no.

El uso de un método de selección por separado para cada campo que desea exponer

La práctica común es tener un método de selección individual para cada campo en su clase que se desea exponer (es decir, el primer ejemplo) . Si esto es una buena práctica o no es discutible porque obliga a una clase a ser mutable. Lo mejor es hacer un objeto inmutable, si es posible, for a number of reasons.

Inicialización sus campos usando un constructor

Una manera de hacer una clase inmutable es mediante la eliminación de los métodos setter y en lugar de hacer sus campos configurables a través de su constructor de la clase, de la siguiente manera. La desventaja de implementarlo de esta manera es que si su clase tiene muchos campos, puede llevar a llamadas de constructor grandes e ilegibles.

public class Address { 
    public String name; 
    public String city; 

    private Address(String name, String city) { 
     this.name = name; 
     this.city = city; 
    } 
} 

Inicialización sus campos usando el Builder

A continuación se muestra una implementación alternativa completamente (inspirado en this article), que es una variación del patrón Builder. Simula la mutabilidad del objeto sin sacrificar la legibilidad.

public class Address { 
    public String name; 
    public String city; 

    private Address() {} 

    private void setName(String name) { 
     this.name = name; 
    } 

    private void setCity(String city) { 
     this.city = city; 
    } 

    static class Builder { 
     private Address address = new Address(); 

     public Builder name(String name) { 
      address.setName(name); 
      return this; 
     } 

     public Builder city(String city) { 
      address.setCity(city); 
      return this; 
     } 

     public Address build() { 
      return address; 
     } 
    } 
} 

Con la clase anterior, se puede crear una instancia de la clase inmutable Dirección de la siguiente manera:

Address address = new Address.Builder() 
     .name("Mansoor's address") 
     .city("Toronto") 
     .build(); 

Qué enfoque utiliza más memoria?

Desde el punto de vista de la memoria, no debería haber ninguna diferencia ya que el tamaño de una clase en la memoria depende de los campos de la clase. Como las tres implementaciones tienen los mismos campos, deberían ocupar la misma cantidad de espacio en la memoria, independientemente del enfoque que utilice.

+0

significa que solo estoy pidiendo métodos setter .. dígame acerca de cualquier método – satheesh

+0

Comentó el aspecto de "métodos en general" en mi respuesta. – aioobe

+0

No estoy de acuerdo con su respuesta. ¿Por qué es una práctica común tener instaladores para cada campo? Con frecuencia, más de uno tiene campos internos en una clase que uno no quiere exponer. El único lugar donde sé que es una práctica común es en frijoles. – Farmor

1

El estándar JavaBean es tener getters y setters para cada propiedad: http://en.wikibooks.org/wiki/Java_Programming/Java_Beans. Si no quiere seguir esa convención estándar, es lo que tiene más sentido para su tienda. Según otras respuestas en este hilo, probablemente haya un delta de memoria mínimo, si hay alguno.

1

Nb.1 sin duda.

Y no escribe ese código a mano, solo declare sus campos.

Luego dejas Eclipse Haz el resto para ti.

En Eclipse use Source -> generate getters and setters.

Una construcción muy similar a la # 2 se hace en el constructor de objetos.

La pregunta actualizada con respecto a la memoria. No se preocupe ni un segundo en el código de producción por la diferencia de memoria entre esas dos formas.

+0

El número 1 es una práctica común, pero fuerza a una clase a ser mutable –

+1

¿Qué quieres decir con eso? ¿No establecería SetAddress ("London", "Uk") y [setName ("Uk") setCity ("London")] igualmente mutable? – Farmor

+0

Ellos lo harían - ni el método es preferible es lo que estoy diciendo. :) –

4

La práctica común es utilizar el estilo JavaBean

class Address { 
    private String name; 
    private String city; 

    public setName(String name){ 
    this.name = name; 
    } 

    public String getName() { 
    return name; 
    } 

    public setCity(String city){ 
    this.city = city; 
    } 

    public getCity() { 
    return city; 
    } 

}

Otra práctica común, que es bastante similar a la suya segundo enfoque es crear objeto inmutable. Los parámetros se pasan al constructor en lugar del método del gran instalador.

class Address { 
    private final String name; 
    private final String city; 

    public Address(String name, String city) { 
     this.name = name; 
     this.city = city; 
    } 

    public String getName() { 
    return name; 
    } 

    public getCity() { 
    return city; 
    } 
} 

Desde el punto de vista de la memoria, la diferencia sería que el segundo ejemplo está poniendo todos los atributos de constructor y todos esos atributos son inmutables. En general, los objetos construidos de esta forma son más seguros cuando son utilizados por múltiples hilos.

En el segundo ejemplo, no hay necesidad de sincronización. Tendría que manejar problemas de sincronización/memoria cuando varios hilos utilizan un objeto JavaBean estándar.

Cuestiones relacionadas