Сколько информации нужно вводить в класс? (ООП)

Я студент-программист на уровне 1-го уровня, хотя я несколько лет занимаюсь программированием, и изучение выше и выше того, чему учит меня класс, - это то, что я делаю, чтобы я был полностью подготовлен как только я выйду в рабочую среду. Этот класс вообще не ООП, а на самом деле следующий класс, но для этого проекта учитель сказал, что он не возражал бы, если бы мы пошли выше и дальше и выполнили проект в ООП (на самом деле вы не можете получить A в его классе, если вы не пройдете выше и дальше в любом случае).

Проект (на данный момент) для чтения в XML файле, байт за байтом, сохраняет теги элемента в одном массиве и значения данных в другом. Я сражался с ним на этом (учитывая рамки .net, связанные с XML), но это была проигранная битва. Он хочет, чтобы мы закодировали это, не используя XML-материал .net.

Он представил пример OOP для этой программы, который он набросал (первоначально написанный на Java, портированный на С++, затем перенесенный с С++ на С#)

В своем примере он получил три класса. первый, XMLObject, который содержит массивы, квази-конструктор, методы getter и setter (не свойства, которые я планирую исправить в моей версии), и метод добавления тегов < и > в теги сохраняться в массивах (и при необходимости выводить на консоль).

Второй класс - это класс parseXML. В этом случае у него есть поля, которые отслеживают количество строк, смещение файла, смещение тега и строки для хранения элементов и данных. Опять же, он получил методы getter и setter, несколько методов анализа, которые ищут разные вещи, и общий метод синтаксического анализа, который использует другие методы анализа (вроде их объединяет). Некоторые из этих методов вызывают вызовы методов класса XMLObject и отправляют проанализированные элементы и значения данных в соответствующие их массивы.

Третий класс, который у него есть, - это тот, у которого нет полей, и имеет два метода: один для выполнения ATOI и один для сброса части потока файлов на консоль.

Я знаю, что мы создаем менее эффективную версию того, что уже включено в инфраструктуру .net. Я указал ему на него, и ему сказали: "Не используйте XML-класс .net, конец обсуждения", поэтому пусть все согласятся просто оставить это один.

Мой вопрос в том, должны ли быть действительно 3 отдельных класса. Разве класс разбора не наследуется от класса объектов XML или просто не кодируется в классе объектов XML, и не должны ли методы ATOI и демпинга быть в одном из этих двух классов?

Мне кажется, что если цель синтаксического анализа в жизни состоит в анализе XML файла и хранении элементов и полей данных в массиве, он должен быть в том же классе, а не изолирован и должен делать это через геттеры и сеттеры (или свойства в версии, которую я собираюсь сделать). Я не понимаю, почему массивы должны быть инкапсулированы в сторону от методов анализа, которые фактически дают им, что хранить.

Любая помощь будет оценена, так как я все еще это проектирую и хочу сделать ее по крайней мере как близкую к "правильной" (я знаю ее относительный термин). Форма ООП.

Ответы

Ответ 1

Во-первых: Если вы находитесь в классе программирования, может быть, это веская причина, по которой он хочет, чтобы вы сделали это вручную: я действительно не рекомендую спорить с вашими профессорами. Вы никогда не выиграете, и вы можете повредить свои оценки.

Во-вторых: его версия не (учитывая тот факт, что это в значительной степени переписывание частей пространства имен System.XML) слишком ужасна. В принципе у вас есть один класс, который "есть" ваш XML. Подумайте об этом как о классах XDocument или XmlDocument: в основном он просто содержит сам Xml. Тогда у вас есть ваш Xml Parser: подумайте об этом, как XmlReader. И ваш последний - своего рода эквивалент XmlWriter.

Помните, что в OOP ваш класс Xml (тот, который представляет сам документ) не должен знать и не заботиться о том, как он попал во владение имеющейся у него информацией. Кроме того, Parser должен знать, как получить Xml, но он не должен заботиться о том, где он хранится. Наконец, ваш класс Writer не должен заботиться о том, откуда поступают данные, только там, где это происходит.

Я знаю, что это слишком часто используется, но думайте о своей программе, как о машине, - у нее есть несколько частей, которые все должны работать вместе, но вы должны иметь возможность изменять любую данную часть, не влияя на другие части. Если вы объединяете все в один класс, вы теряете эту гибкость.

Ответ 2

Общее правило состоит в том, что мы подсчитываем размер класса в количестве обязанностей, которые он имеет:

Класс должен иметь один ответственность: единственная причина для изменение.

Мне кажется, что ваш учитель правильно отделил свои обязанности. Он отделил представление от логики синтаксического анализа xml, и он отделил данные xml от поведения анализа XML.

Ответ 3

Некоторые моменты:

  • Классы - существительные; методы - глаголы.
    Ваш класс должен называться XmlParser.

  • Поскольку синтаксический анализатор XML не является частью XMLObject и не расширяет XMLObject, он должен быть отдельным классом.

  • Третий класс не имеет ничего общего ни с одним из двух других; это просто обычный класс Utilities.

  • В целом, каждый класс должен отвечать за единицу работы или хранения.
    Не пытайтесь вкладывать слишком много в один класс (см. Анти-шаблон "Объект Бога" ).
    Нет ничего плохого в том, что у меня много классов. (Пока все имеют смысл)

Ответ 4

Обобщите, что должна делать система:

  • для чтения в XML файле, байт по байту,
  • хранить теги элементов в одном массиве,
  • значения данных для другого.

Я бы, вероятно, нарезал его следующим образом:

  • Reader: заданный путь к файлу, выводит содержимое побайтно (IEnumerable<byte>)
  • Tokenizer: при перечислении байтов выдает токены, относящиеся к XML-контексту (IEnumerable<XmlToken>)
  • XmlToken: базовый класс для любого результата, который производит токенизатор. Пока вам нужны 2 специализации:
    • Тег: открывающий тег
    • Значение: содержимое тега
  • TokenDelegator: принимает токенизатор и экземпляр
  • IXmlTokenVisitor: (см. шаблон посетителя)
  • TagAndValueStore: реализует IXmlTokenVisitor. Visit(Tag tag) и Visit(Value value) являются имплантированными, а соответствующий контент хранится в массивах.

Понимаете, я закончил с 7 классами и 1 интерфейсом. Но вы можете заметить, что вы заложили основы для полноценного анализатора XML.

Часто код, который продается как OO, просто нет. Класс должен придерживаться принципа единой ответственности.