c# - que - ¿Cuánta información debo poner en una clase?(OOP)

que es un objeto en programacion

Question

Soy un estudiante de programación de C # de primer nivel, aunque he estado incursionando en la programación durante algunos años, y aprender más allá de lo que la clase me enseña es justo lo que estoy haciendo para estar completamente preparado una vez que llegue en el ambiente de trabajo. Esta clase en particular no es OOP en absoluto, en realidad es la siguiente clase, pero para este proyecto, el maestro dijo que no le importaría si hiciéramos todo lo posible e hiciéramos el proyecto en OOP (de hecho, no puede obtener una A). en su clase a menos que vayas por encima y más allá de todos modos).

El proyecto es (en este punto) leer en un archivo XML, byte por byte, almacenar etiquetas de elementos en una matriz y los valores de datos en otra. Luché con él en esto (dados los marcos .net que tratan con XML) pero esa fue una batalla perdida. Quiere que codifiquemos esto sin usar .net XML.

Él proporcionó un ejemplo de OOP para este programa que se dividió (originalmente escrito en Java, portado a C ++, luego portado de C ++ a C #)

En su ejemplo tiene tres clases. el primero, XMLObject , que contiene los arreglos, un cuasi constructor, métodos de obtención y establecimiento (no propiedades, que planeo corregir en mi versión), y un método para agregar las etiquetas < y > a las etiquetas que se almacenarán en los arreglos ( y salida a la consola si es necesario.

La segunda clase es una clase parseXML . En este tiene campos que realizan un seguimiento del recuento de líneas, desplazamiento de archivos, desplazamiento de etiquetas y cadenas para contener elementos y datos. Una vez más, tiene métodos de obtención y establecimiento, varios métodos de análisis que buscan diferentes cosas, y un método de análisis general que utiliza los otros métodos de análisis (de alguna forma los combina aquí). Algunos de estos métodos realizan llamadas a los métodos de la clase XMLObject y envían el elemento analizado y los valores de datos a sus matrices respectivas.

La tercera clase que tiene es una que no tiene campos, y tiene dos métodos, uno para hacer ATOI y otro para volcar una parte de la secuencia de archivos a la consola.

Sé que básicamente estamos construyendo una versión menos eficiente de lo que ya está incluido en el marco .net. Le señalé esto a él y me dijeron "no use la clase XML de .net, fin de la discusión", así que acordemos dejar eso solo.

Mi pregunta es si deberían ser realmente 3 clases separadas. ¿No debería la clase de análisis heredar de la clase de objeto XML, o simplemente estar codificada en la clase de objeto XML, y el ATOI y los métodos de descarga no deberían estar también en una de esas dos clases?

Para mí, tiene sentido que si el objetivo de la clase de análisis en la vida es analizar un archivo XML y almacenar elementos y campos de datos en una matriz, debería estar en la misma clase en lugar de estar aislado y tener que hacerlo a través de captadores y definidores ( o propiedades en la versión que voy a hacer). No veo por qué las matrices deberían encapsularse lejos de los métodos de análisis que realmente les dan qué almacenar.

Cualquier ayuda sería apreciada, ya que todavía estoy diseñando esto, y quiero hacerlo al menos lo más cerca posible de la forma de "POP" (sé que es un término relativo).

Answer 1

Algunos puntos:

• Las clases son sustantivos; Los métodos son verbos.
  Tu clase debería llamarse XmlParser .

• Como el analizador XML no forma parte del objeto XMLO ni lo amplía, debería ser una clase aparte.

• La tercera clase no tiene nada que ver con ninguno de los otros dos; Es solo una clase ordinaria de Utilities .

• En general, cada clase debe ser responsable de una sola unidad de trabajo o almacenamiento.
  No intente poner demasiado en una sola clase (vea el antipatrón "objeto de Dios").
  No hay nada de malo en tener muchas clases. (Mientras todos tengan sentido)

Answer 2

La regla general es que contamos el tamaño de una clase en el número de responsabilidades que tiene:

Una clase debe tener una sola responsabilidad: una sola razón para cambiar.

Me parece que tu maestro separó sus responsabilidades correctamente. Separó la presentación de la lógica de análisis xml y separó los datos xml del comportamiento de análisis xml.

Answer 3

Primero: si estás en una clase de programación, puede haber una buena razón por la que quiere que lo hagas a mano: realmente no recomiendo discutir con tus profesores. Nunca ganarás, y puedes dañar tus calificaciones.

Segundo: su versión no es (considerando el hecho de que es en gran parte una reescritura de partes del espacio de nombres System.XML) demasiado terrible. Básicamente tienes una clase que "es" tu XML. Piense en ello como las clases XDocument o XmlDocument: Básicamente solo contiene el mismo Xml. Luego tienes tu Xml Parser: piensa en eso como XmlReader. Y tu último es una especie de su equivalente de XmlWriter.

Recuerde que con la POO, su clase Xml (la que representa el documento en sí) no debe saber ni importar cómo llegó a poseer la información que tiene. Además, el analizador debería saber cómo obtener el Xml, pero no debería importarle mucho dónde se almacena. Finalmente, a su clase de Escritores no debería importarles de dónde provienen los datos, solo a dónde van.

Sé que se usa en exceso, pero piense que su programa es como un auto; tiene varias partes que deben funcionar juntas, pero debería poder cambiar cualquier parte del mismo sin afectar en gran medida a las otras. Si agrupas todo en una clase, pierdes esa flexibilidad.

Answer 4

Resumamos lo que debe hacer el sistema:

• para leer en un archivo xml, byte por byte,
• almacenar etiquetas de elementos en una matriz,
• Los valores de los datos a otro.

Probablemente lo cortaría de la siguiente manera:

• Lector: dada una ruta de archivo, produce el contenido en bytes ( IEnumerable<byte> )
• Tokenizer: dada una enumeración de bytes, genera tokens relevantes para el contexto XML ( IEnumerable<XmlToken> )
• XmlToken: clase base para cualquier salida que produzca el tokenizador. Por ahora necesitas 2 especializaciones:
  • Etiqueta: Una etiqueta de apertura
  • Valor: Contenido de una etiqueta
• TokenDelegator: Acepta un Tokenizer y una instancia de
• IXmlTokenVisitor: (Ver patrón de visitante)
• TagAndValueStore: implementa IXmlTokenVisitor. Se implementan Visit(Tag tag) y Visit(Value value) y el contenido relevante se almacena en arreglos.

Verás, terminé con 7 clases y 1 interfaz. Pero puede notar que ha sentado las bases para un analizador XML completo.

A menudo, el código que se vende para ser OO simplemente no lo es. Una clase debe adherirse al principio de responsabilidad única.