Объектно-ориентированный анализ и реальные ООП различия - PullRequest
4 голосов
/ 25 апреля 2009

Я обычно пытаюсь сделать TDD с небольшим анализом (без диаграмм) перед началом кодирования. Обычно я разделяю класс на другие, чтобы разделить проблемы. Интересно, не поможет ли это более глубокий анализ? Я думаю, что большая часть анализа ОО не может предсказать некоторые из этих случаев. Что ты думаешь?

Ответы [ 4 ]

4 голосов
/ 25 апреля 2009

Для меня разделение классов обычно является частью процесса обучения. Либо о проблемной области, либо о процессе кодирования. И обычно я делаю это во время кодирования. Иногда я приношу одного или двух сотрудников к доске для обсуждения вещей.

TDD должен позволить вам сосредоточиться на проблеме, которую вы пытаетесь решить. Тот факт, что вы узнаете о структуре проблемы по мере ее решения, является неотъемлемой частью TDD. Не вдавайтесь в большие предварительные процессы анализа / проектирования.

2 голосов
/ 25 апреля 2009

«Обычно я делю класс на другие классы, чтобы разделить проблемы. Интересно, не предотвратит ли это более глубокий анализ. Я думаю, что большая часть анализа ОО не может предсказать некоторые из этих случаев».

У меня есть подобный опыт в этом отношении. TDD помогает вам лучше разрабатывать классы, которые Я не вхожу в A & D.

Тем не менее, я нашел предварительный анализ очень полезным. Это как заложить основы анализа, и тогда вы получите детальный дизайн во время кодирования.

Некоторые вещи просто нужно смотреть с более широкой перспективы.

1 голос
/ 25 апреля 2009

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

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

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

OTOH, обещание XP и рефакторинга заключается в том, что вы можете исправить проблемы при первоначальной факторизации проблемы, когда требования подталкивают вас в этом направлении. Я думаю, что это правда, но вы все равно будете более ценным вкладчиком, если сможете принять правильные решения с первого раза. И сделать так, чтобы это выглядело как удача - «Испытания заставили меня учесть это таким образом» - это часть навыка.

0 голосов
/ 25 апреля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...