¿Comprender el comportamiento de las clases en la programación orientada a objetos?
En primer lugar, creo que deberías aclarar la diferencia entre "clase" y "objeto".
1 El comportamiento es generalmente un concepto subjetivo, pero los objetos que diseñamos generalmente no lo son. Ser proactivo requiere factores externos para promover el comportamiento ¿No es esto contradictorio?
A1: No hay ninguna contradicción. El comportamiento puede considerarse como la capacidad del objeto. Tener este "comportamiento" en realidad significa que el objeto tiene esta "capacidad de comportamiento" y tiene la capacidad y autoridad. Para hacerlo, la activación de factores externos generalmente se llama y pasa parámetros, es decir, "dejamos que haga esto". En otras palabras, no tienes que hacer esto si tienes esta habilidad. Sin ella, será inútil sin importar cómo la actives.
Ejemplo: escribo una clase de Cuenta. Si no se le proporciona el comportamiento de inicio de sesión, entonces es solo una lista. Si se le da el comportamiento de inicio de sesión, entonces podemos iniciar sesión en la cuenta llamando. este comportamiento.
Por el contrario, si no escribimos un comportamiento de inicio de sesión en la clase Cuenta, la consecuencia es que debemos escribir el mismo código de inicio de sesión en cada lugar donde deba iniciar sesión una cuenta, lo que provoca que code to Chaos
-----Soy la línea divisoria del dolor-----
2. Aunque las clases tienen estas dos características, parece que algunas. La clase solo la llaman personas. Como clase de nivel más bajo, no parece requerir ningún comportamiento. Pero ¿por qué algunos análisis le añaden comportamiento? (Como se muestra en la imagen: la clase de cuenta debe ser algo así como una tabla de lista. Es comprensible que la clase de cajero automático tenga el comportamiento operativo de iniciar sesión en la cuenta, pero parece un poco inapropiado que la lista de cuentas también tenga el inicio de sesión comportamiento.) ¿Cómo se debe solucionar el establecimiento de clases en el proyecto?
To2: El inicio de sesión de la cuenta y el inicio de sesión de la cuenta son completamente dos conceptos. Si sigue el contenido del ejemplo, lo escribiré así
El comportamiento de inicio de sesión de la clase Cuenta: compare el nombre y la contraseña en la base de datos; si tiene éxito, modifique el estado de inicio de sesión a 1 y lea varios datos, como El monto del depósito es de Shenma; si falla, devuelve -1 (si se expande aún más, también puede configurar un contador para el número de inicios de sesión fallidos. Después de que el número acumulado llegue a X, se iniciará sesión en Shenma). prohibido).
El comportamiento LoginAccount de la clase ATM: obtenga un nombre y una contraseña de la interfaz de usuario, cree un nuevo objeto Cuenta, establezca los atributos de nombre y contraseña de este objeto y luego llame al comportamiento Login de este objeto. . Luego reacciona según el resultado de la llamada.
--------La línea divisoria de Shenma aparece nuevamente------
En resumen, creo que tu problema radica principalmente en confundir las "clases". diferencia entre "objeto" y "objeto"
Se puede ver en el hecho de que "la clase de cuenta debe ser una tabla de lista o algo así". De hecho, la tabla de lista real está en la base de datos. y el papel de la clase de cuenta debe ser Se refleja en "si la cuenta existe" y "qué operaciones se pueden realizar en la cuenta".
Especialmente el último concepto, la llamada clase inferior, puede Sólo significa que su comportamiento no realiza operaciones sobre objetos de otras clases. Operación, su función es sólo comunicarse entre el programa y la base de datos o operar sus propios atributos.
En el aprendizaje orientado a objetos, como. En la medida de lo posible, el funcionamiento de los propios atributos del objeto debe estar sellado en el comportamiento del objeto mismo. Si el objeto A puede modificar las propiedades del objeto B, sucederá algo terrible que provocará el caos en todo el programa. >