Читайте также:
|
Объектно-ориентированное программирование - это новый и отличный путь думать о программировании. Большинство людей имеют проблемы при первом знании о том, как подступить к ООП проекту. Так как вы знаете, что все можно представить объектом, и так как вы учитесь думать в более объектно-ориентированном стиле, вы можете начать создавать “хороший” дизайн, который использует все преимущества, которые предлагает ООП.
Метод (часто называемый методологией) - является набором обработок и процедур, используемых для разбиения сложной проблемы программирования. Многие методы ООП уже сформулированы еще на расцвете объектно-ориентированного программирования. Этот раздел даст вам почувствовать, что вы пытаетесь достигнуть, когда используете метод.
Особенно в ООП методология - поле для многих экспериментов, что особенно важно для понимания, что метод - это попытка решить проблему, прежде чем вы выберите решение. Это особенно верно в Java, где язык программирования предназначен для снижения сложности (по сравнению с С) возникающей в выражениях программ. Это, фактически, может смягчить необходимость во всех-более-сложных методологиях. Вместо этого простых методологий может хватить в Java для большинства типов проблем, которые вы можете встретить, используя простые методологии с процедурными языками.
Так же важно понять, что “методология” часто очень важна и обещает очень много. Что бы вы ни делали при разработке и написании программы - это метод. Это может быть ваш собственный метод и вы можете не осознавать этого, но это процесс, которым вы следуете, создаете. Если это эффективный процесс, для него необходимо только небольшая настройка при работе с Java. Если вы не удовлетворены вашей производительностью и путем, которым идет ваша программа, вы можете захотеть выбрать формальный метод или выбрать часть из большого количества формальных методов.
Пока вы следуете процессу разработки, наиболее важная проблема при этом: не потеряться. Это легко сделать. Большинство из методов анализа и дизайна предназначены для решения больших проблем. Помните, что большинство проектов выходят за рамки категории, так что вы можете обычно иметь удовлетворительный анализ и дизайн с относительно малым числом рекомендаций метода. [8]. Но некоторый сорт процессов, не имеет значения чем ограничено, будет заставлять вас на вашем пути поступать гораздо лучше, чем просто начинать кодировать.
Легко попасть в ловушку и впасть в аналитический паралич, где вы почувствуете, что вы не можете двигаться вперед, потому что вы не сможете обнаружить каждую малую деталь в текущем состоянии. Помните, не имеет значения, сколько анализов вы выполнили, есть некоторые вещи, относительно системы, которые не откроют себя во время дизайна, а многие вещи не откроют себя, пока вы не начнете программировать или даже пока программа не будет запущена. По этому, важно быстро перейти от анализа и дизайна к реализации теста предполагаемой системы.
Это места заслуживает особого внимания. Исходя из истории процедурных языков, похвально то, что команда продвигается осторожно и каждую минуту разбирает и понимает детали, прежде чем перейдет к дизайну и реализации. Конечно, когда создаете DBMS, необходимо понять требования потребителя. Но DBMS - это классическая проблема, которая хорошо поставлена и хорошо понята; в большинстве таких программ структура базы данных является проблемой для решения. Класс проблем программирования, обсуждаемый в этой главе - из “неопределенного (wild-card)” (мой термин) разнообразия, в котором решение - это не просто переформирование хорошо известного решения, а привлечение одного или нескольких “неопределенных (wild-card) факторов” — элементов, для которых нет хорошо известных предыдущих решений, и для которых необходимо исследование [9]. Попытка полного анализа неизвестной проблемы до перехода к дизайну и реализации приводит к параличу анализа, так как вы не имеете достаточно информации для решения проблем такого рода в фазе анализа. Решение таких проблем требует циклического приближения, а это источник рискованного поведения (которое дает понимание, так как вы пробуете выполнить что-то новое и потенциально вознаграждает и повышает знания). Это выглядит как риск, получаемый при “броске” к предварительной реализации, но это может снизить в неопознанном проекте, потому что вы рано выясняете, является ли обычный подход к проблеме жизнеспособным. Разработка продукта - риск в управлении.
Часто получается, что вы “строите одно, чтобы выбросить”. В ООП вы можете выбросить часть, потому что код инкапсулируется в класс, во время первого прохода вы неизбежно создадите определенный полезный дизайн класса и разработаете полезные идеи относительно разрабатываемой системы, которые нет необходимости выбрасывать. Таким образом, первый проход цикла по проблеме не только даст важную информацию для следующего прохода анализа, дизайна и реализации, он также создаст основу кода.
Говорят, что если вы смотрите на методологию, создающую огромное число деталей и предлагающую много шагов и документов, все еще тяжело понять, когда остановиться. Держите в уме, что вы пробуете узнать:
Если вы не приобрели ничего, кроме объектов и их интерфейсов, вы можете писать программу. По разным причинам вам может быть необходимо более подробное описание и документация, чем эта, но вы не можете избежать неприятностей.
Процесс может быть разбит на пять частей, и Фаза 0 является обязательной начальной ступенью для использования определенной структуры.
Фаза 0: Создание плана
Сначала, вы должны решить, какой шаг вы совершаете в вашем процессе. Это звучит просто (фактически, все это звучит просто), и при этом люди часто не делают этого решения до начала кодирования. Если ваш план: “впрягаемся и начинаем кодировать” - прекрасно. (Иногда это работает, когда вы имеете хорошо понятую проблему.) Согласитесь, что меньше всего - это планом.
Вы можете также решить на этой фазе, что необходимы некоторые дополнительные структуры обработки, но не все девять ярдов. Понятно, что некоторые программисты любят работать в “свободном режиме”, в котором не навязываются структуры в процесс разработки их работы; “Это будет выполнено, когда будет сделано”. Это может нравиться какое-то время, но я обнаружил, что есть несколько вех на пути, помогающих сфокусировать и сосредоточить ваши усилия вокруг этих вех, вместо того, чтобы застрять на единичной цели “завершить проект”. В дополнение, это разделяет проект на меньшие составные кусочки и делает его менее запутанным (плюс вехи часто более удобны для празднования).
Когда я начинал учить структуру магазина (так что я иногда писал новеллу) я сначала сопротивлялся идеи структуры, чувствуя, что я напишу лучше, если просто позволю течь на страницу. Но позже я понимал, что когда я пишу о компьютерах, структура достаточно понятна для меня, так что мне не нужно думать об этом очень много. Но я все еще структурировал мою работу, хотя только наполовину осознавал ее в моей голове. Даже если вы думаете, что ваш план - просто начать кодирование, вы все еще почему-то проходите последовательность фаз, ставя определенные вопросы и отвечая на них.
Дата добавления: 2015-09-11; просмотров: 94 | Поможем написать вашу работу | Нарушение авторских прав |