¿Es realmente necesario que cada clase en la capa de Servicio y en la capa Dao agregue una interfaz?

En pocas palabras, depende de la situación.

Depende principalmente de su proyecto:

Por ejemplo, si la hibernación utilizada originalmente por el proyecto puede cambiarse a mybatis en el futuro, entonces dao necesita usar la interfaz. Esto no afectará la modificación del código superior.

Para otro ejemplo, si el proyecto es una sola aplicación, cualquier modificación del código requiere volver a compilar todo el proyecto, por lo que no se necesita ninguna interfaz. Si el proyecto se compila e implementa en módulos, puede usar el desacoplamiento de interfaz. Si se modifica el dao, solo necesita volver a compilar e implementar el módulo dao sin afectar el módulo de la capa superior.

A continuación, si hay muchos novatos en el equipo del proyecto, una estructura de código simple puede ser más adecuada. El costo de aprendizaje de estructuras de proyectos complejos es mayor.

Si el avance del proyecto es muy urgente, puedes utilizar una forma sencilla y cruda de hacerlo primero.

Puedes utilizar los costes económicos para explicar el motivo.

La definición de costo en economía es: Cuando haces una cosa, entre las otras cosas que abandonas, el valor de la cosa con mayor valor es el costo de hacerla.

El costo de usar la interfaz es el costo de no usar la interfaz (incluidos los costos de mantenimiento posteriores).

Si hay muchos cambios en el proyecto, despliegue de módulos y el proyecto no es urgente, entonces el coste de usar la interfaz será menor que el coste de no usar la interfaz, aunque pueda parecer más sencillo en los primeros días sin usar la interfaz, por el contrario, el costo de no usar la interfaz será bajo, e incluso no es necesario usar el marco.

Después de todo, las herramientas sirven para mejorar la eficiencia, ¿por qué molestarse con ellas? ¡tú mismo!

Tu reflejo demuestra que has abierto tu coeficiente intelectual. También le he preguntado a muchos programadores, incluyéndome a mí, ¿por qué cada vez que escribo una clase, tengo que encontrar una interfaz y luego escribir una clase de implementación Impl? Ningún programador pudo responder correctamente. La mayoría de ellos dijeron que los maestros o los libros lo enseñaban de esta manera, y también lo hicieron de esta manera cuando aprendieron el marco de primavera. Alguien también respondió antes que la interfaz es estable, pero que la clase de implementación es inestable y debe cambiarse con frecuencia. Pero, por lo general, el código lo escribe usted mismo. ¿No sabe si es estable o no? Si hay que cambiarlo, ¿no sería más laborioso cambiar también el puerto de conexión? Entonces, si piensas profundamente, tendrás que cuestionar incluso el marco de primavera.

Así que mi conclusión es que los hábitos de desarrollo interno conducen a esta pregunta. Porque como desarrollo en equipo, el hábito de desarrollo estándar es escribir la interfaz y los casos de prueba primero, y la clase de implementación incluso escribirá un pseudocódigo para garantizar que el código de prueba se pueda ejecutar correctamente. El desarrollo de software basado en pruebas debe separar la implementación y la interfaz. La evolución de la arquitectura J2EE a Spring sigue este objetivo.

La realidad es que un programador maneja varias capas por sí mismo, y luego no tiene una línea de código de prueba. En este caso, escribir una interfaz y luego una clase de implementación para cada clase sería superfluo.

Esta es mi opinión. Los comentarios son bienvenidos.

Esto es culpa de Spring en los primeros días, no había cglib, solo dinámica Jdk. De lo contrario, las funciones relacionadas con los aspectos no serían posibles. . . . Más tarde, cuando se cambió cglib, no existía tal requisito obligatorio, pero muchas personas continuaron con este hábito.

Esta pregunta es una muy buena pregunta y muchos programadores entraron en contacto con ella cuando comenzaron a trabajar. Todos los proyectos hacen esto, con una interfaz correspondiente a una clase de implementación, y luego mantienen este hábito, pero es posible que no hayan pensado por qué lo hacen o cuáles son los beneficios.

Desde una perspectiva de ingeniería, la programación orientada a interfaz es necesaria, pero aún debemos considerarla en función de la situación real.

“Si la clase de implementación puede cambiar, es mejor utilizar programación orientada a interfaz para desacoplar cada capa de código y reducir la carga de trabajo de modificaciones posteriores.

"¿Pero realmente cambiará más adelante?

Esta frase parece no ser un problema. Por ejemplo, si queremos implementar una función de envío de mensajes de texto a los usuarios:

Al principio del proyecto, la empresa compró el servicio de Alibaba Cloud y llamó directamente a una interfaz de Alibaba Cloud para enviar mensajes de texto después de que el proyecto estuvo en ejecución durante un período de tiempo, se cambió para cooperar con Tencent Cloud, por lo que el código para el envío de mensajes de texto debía modificarse para evitar que el líder dijera "volver a cambiarlo". "Escribamos una interfaz y dos implementaciones aquí. Será mucho más conveniente si los métodos de nivel superior solo se escriben para la interfaz.

Sin embargo, todo esto es "imaginado" por nosotros. Al menos he estado trabajando durante más de diez años y casi nunca he visto requisitos tan cambiantes en cuanto a agregar interfaces a la capa Dao. Para evitar la migración de bases de datos en el proyecto, tengo que cambiar de Oracle a MySQL...

“Una interfaz equivale a un estándar y una especificación. Las personas que formulan la interfaz y las personas que implementan la interfaz. Puede que no sean las mismas personas. "¿Qué pasa si están en el mismo proyecto?

Esta frase no es incorrecta. Por lo general, esta situación es adecuada para la programación orientada a interfaz, como la implementación de JDBC:

En esta vez la interfaz La formulación, la implementación de la interfaz y el uso de la interfaz son diferentes;

Pero ¿qué pasa si están en el mismo proyecto?

Entonces, en nuestro proyecto, la interfaz y la clase de implementación. generalmente son uno por uno, y los desarrolladores son los mismos y no hay posibilidad de cambiar la clase de implementación, ¿aún es necesario programar para la interfaz?

Puedes considerar los siguientes aspectos:

Excepto en los escenarios anteriores donde es necesario o mejor usar interfaces, creo que siempre que el proyecto sea de una escala ligeramente mayor, es mejor desarrollar para interfaces, incluso si una interfaz corresponde a una clase de implementación cuando lideras un equipo, el equipo puede no ser grande, solo hay tres o cinco desarrolladores, pero a medida que el proyecto avanza y se itera, si no utilizas el desarrollo orientado a la interfaz, te sorprenderá descubrir que el código del proyecto se vuelve cada vez más complejo y confuso, con una clase que tiene docenas de métodos y un método tiene cientos de líneas de código, y los nuevos miembros del equipo están confundidos, incluso usted, el administrador del proyecto, no quiere leer el código. ;

No menciones establecer especificaciones de código, las especificaciones siempre están ahí, pero siempre hay personas que no las cumplen y es imposible evitarlas;

Si el Servicio. La capa y la capa Dao del proyecto son clases de implementación de interfaz, el código aún se puede leer la mayor parte del tiempo, lo que equivale a Hay un directorio de métodos adicional, que permite a los desarrolladores, por ejemplo, ver si pueden reutilizar los anteriores. métodos antes de escribir un nuevo método;

Por supuesto, si no hace esto, los desarrolladores también pueden implementarlo directamente. Mirar los métodos existentes en una clase es relativamente hablando, buscar en un directorio con docenas o cientos de líneas y buscar en una clase de implementación con miles de líneas (aunque hay varios métodos abreviados para enumerar los métodos), es más fácil que el primero.

Continuaré compartiendo mis conocimientos sobre Java. desarrollo, diseño de arquitectura, desarrollo profesional de programador, etc., y espero llamar su atención.

Hola a todos, soy un tío de Internet. Hoy responderé esta pregunta. Primero, estilo de codificación

Cuando todo el mundo escribe código, de hecho, siempre que tengas cierta experiencia, habrás oído hablar de una palabra, que es estilo de codificación. He leído algunos libros, como por ejemplo. Como "La belleza del código" y "Enciclopedia del código". De hecho, el concepto que se analiza en estos libros es: Escribir código es lo mismo que traducir. Lo que hay que tener en cuenta es "fidelidad, expresividad y elegancia". "Por lo tanto, al escribir código, especialmente en proyectos a gran escala creados por muchas personas, no solo debe asegurarse de que la lógica del código sea correcta, sino también de que el código sea correcto. El estilo es bueno y fácil de leer, y el Los comentarios deben estar escritos claramente. De esta manera, no habrá problemas importantes durante la coordinación continua y la iteración y el mantenimiento posteriores.

En segundo lugar, la pregunta planteada por la pregunta también es un tipo de estilo de codificación.

La pregunta mencionada por la pregunta es en realidad un tipo de estilo de codificación. Lógicamente hablando, eres completamente tú. No es necesario agregar interfaces a ninguna clase. En ese caso, su código no causará ningún problema y aún podrá ejecutarse correctamente. Pero cuando lo escribes de esta manera, la idea será confusa y parecerá más laboriosa cuando otros llamen a los métodos de tu clase. Si hay problemas con la transferencia de código en el futuro, será más problemático.

De hecho, al escribir código JAVA, primero debes abstraer la interfaz y luego implementar la clase una vez finalizada. Esto es como escribir un artículo. Antes de escribir el artículo, primero haga un esquema y luego escriba basándose en él, para que la idea no sea caótica. Y cuando otros miren su esquema, sabrán cuál es el contenido principal de su artículo.

En tercer lugar, hablemos del estilo de codificación de Xin Daya

1. Xin Daya

Lo más importante al desarrollar código es que el código pueda ejecutarse sin problemas y el la lógica es correcta Sí, la menor cantidad de errores posible. Esto es "confianza", su código es digno de confianza. Todo el mundo conoce el estilo de Baidu: sencillo y fiable. El código que proporcione debe ser confiable y todos puedan usarlo con confianza.

2. Da

Su código debe ser accesible, la lógica clara y los comentarios e interfaces claros. Debe tener buenos resultados de código y estilo de codificación, como la denominación de los campos. y métodos. Trate de "comprender el significado del texto" tanto como sea posible.

3. Elegancia

Esto es elevarse al nivel del arte. Tu código debe tener diseño y belleza. No estás escribiendo código, estás haciendo una obra de arte. El tío aún no ha alcanzado este nivel, así que no escribirá tonterías.

No hagas patrones por patrón.

El propósito del uso de interfaces es facilitar el mantenimiento y la expansión de la lógica empresarial y el acceso a los datos en el futuro. Esta es la idea de la programación orientada a objetos: el polimorfismo.

Cuando empiece a escribir, sentirá que ha escrito un archivo de interfaz adicional, que no sirve de nada. Pero cuando tienes más y más código, lo que llamas no es una interfaz, sino una clase específica. Cuando es necesario realizar cambios, solo puede tener dos opciones: una es refactorizar los nombres de las clases en todos los códigos de llamada y la otra es modificar directamente el servicio o dao original. Ambos enfoques son más propensos a errores cuando el proyecto es complejo. Puede imaginar que si hay 1000 métodos que llaman a una determinada clase dao, cuando necesita cambiar el dao de mysql a Oracle, debe cambiar el nombre de la clase que llama en los 1000 métodos.

Si el lugar al que llama es una interfaz, no es necesario cambiar el tipo de variable de objeto en el método. Solo necesita escribir la implicación de un nuevo servicio o dao, o el nuevo servicio o dao hereda el anterior y solo reescribe algunos métodos. Cuando se usan, todas las interfaces que llaman a servicio o dao pueden usar la nueva clase o método de implementación mediante inyección.

Esto es necesario. Nuestro manual de desarrollo no permite que los métodos en la capa de Servicio sean métodos que no implementen la interfaz.

En la capa DAO, si se usa Mybatis3.0 o superior, todos los métodos que escribimos se basan en interfaces, por lo que este problema no existe.

En la capa de Servicio, debemos definir interfaces para la especificación de código y la reutilización de métodos. Para dar un ejemplo simple:

En uno de nuestros sistemas comerciales, puede haber múltiples módulos comerciales con métodos CRUD. Entonces necesitamos definir agregar, obtener, actualizar, etc. CRUD en los métodos de cada Servicio. método de interfaz? Por supuesto que no. Solo necesitamos definir una interfaz, definir estos métodos en la interfaz y luego implementar estas interfaces en las clases comerciales correspondientes y luego implementar estas interfaces en sus respectivas clases de implementación.

Por lo tanto, para la especificación del código y la reutilización de interfaces, necesitamos definir interfaces.

Da un ejemplo sencillo reciente. ¿Necesitas barras de acero para construir una casa?