2012-06-27 15 views
13

Digamos que tengo un archivo CSV y creo una clase llamada CsvFile que se extiende desde java.io.File. Esta clase puede analizar un archivo CSV y devolver algunos datos, como cuántas columnas hay en el archivo. También se puede usar para funciones que toman java.io.File como entrada. Como F ileUtils.copyFile(File from, File to).¿La herencia romperá la encapsulación?

Mi colega cree que exponer demasiado de la herencia. Su idea es envolver java.io.File manteniéndolo en una propiedad privada, en lugar de heredarlo. Él piensa exponer todos los métodos/propiedades públicas de la encapsulación de los cortes de archivos, pero lo tomo como un beneficio ya que obtenemos todas las funciones en java.io.File de forma gratuita.

¿Qué opinas?

+0

Cualquiera o creo que no, pero la combinación de ambos es el camino. Primera herencia para que la rueda no se reinvente, que para patrones que encapsulan para que la rueda cumpla su propósito. –

Respuesta

15

yo preferiría estar de acuerdo con su colega: heredar java.util.File expondría métodos que no son aplicables a CsvFile objetos, tales como list(), listFiles(), setExecutable(), y así sucesivamente.

Hacer una propiedad detrás de un getter suena como una mejor opción: no revela operaciones irrelevantes para los usuarios de su clase, y le permite heredar de una clase base de su elección.

+1

para agregar a la respuesta: sí, en este caso la herencia romperá la encapsulación al filtrar los detalles de la implementación que un archivo CVS se implementa utilizando un archivo java.io.File – Soronthar

+1

podría no ser un caso de cualquiera de los dos. Heredar para personalizar, luego de envolver para limitar a los métodos que desea exponer. –

+0

Cualquiera o creo que no, pero la combinación de ambos es el camino. Primera herencia para que la rueda no se reinvente, que para patrones que encapsulan para que la rueda cumpla su propósito. –

5

Creo que todo depende del propósito de la clase. Si realmente intentas extender el comportamiento, diría que tiene sentido. Si no está extendiendo el comportamiento de File pero solo está haciendo un objeto CSV, entonces la encapsulación limitaría sus comportamientos a solo lo que su intención es.

1

También podría considerar hacerlo más genérico para que pueda aceptar un InputStream o Reader con formato CSV de una amplia variedad de fuentes que no pueden (o no pueden) emitir fácilmente al sistema de archivos. Todavía puede tener un setter/constructor de archivos java.io para su comodidad.

1

Esto es realmente un gran debate. Tu colega está en el lado correcto de la historia en este caso. En general, la cuestión de la herencia se reduce a las relaciones de is-a vs. has-a. En general, es más flexible usar composición que herencia. En tu caso, es una llamada cercana. Después de todo, un archivo csv es un archivo. diciendo que csvfile tiene un archivo que ni siquiera suena bien. Lo que también se puede considerar es hacer la herencia, pero luego envolver el archivo heredado para que solo se expongan los métodos de archivo CSV que desee. También buscaría algunos patrones de diseño en torno a esto en los que quiera heredar de A pero exponga una interfaz más limitada al mundo. Estoy casi seguro de que hay un patrón de diseño para esto. simplemente no puedo recordar el nombre ...

"O no, o creo que no, pero la combinación de ambos es el camino. Primera herencia para que la rueda no se reinvente, que para patrones que encapsulan para que la rueda sirva propósito."

0

Tal vez mi punto de vista es demasiado liberal, pero ... La encapsulación y la herencia están ahí por algún motivo. (Observe la 'evolución' de los ensambladores a los lenguajes de alto nivel.) Esa razón es el programador. Con abstracciones/paradigmas de nivel superior puedes escribir mejor código. El truco es definir "mejor", por supuesto. Para mí esto es capacidad de mantenimiento, auto-documentación y reutilización de código. Es por eso que elegiría la encapsulación sobre la herencia en su caso particular. Quizás es un poco más difícil escribirlo una vez, pero es mucho más fácil de mantener en el futuro. (Asumiendo que este material CSV es parte de un proyecto más grande, por supuesto).

0

El enfoque que menciona su colega también tiene el beneficio de que su API se vuelve muy pequeña al exponer los métodos que realmente necesita, lo que deja en claro cómo el usuario cómo usar tu clase (puedes pensar en tu API pública como algún tipo de documentación).

0

cuanto a su pregunta

Se herencia encapsulación descanso?

Entonces, de acuerdo a Java eficaz de Joshua Bloch, la herencia siempre se rompe la encapsulación:

A diferencia de la invocación de métodos, herencia viola la encapsulación [Snyder86]. En otras palabras, una subclase depende de la implementación detalles de su superclase para su correcto funcionamiento.

En cuanto a si se debe utilizar la herencia o la composición, ya que muchas personas ya se ha dicho, depende de si su CsvFile es-un archivo, en el sentido de java.util.File.