Изучение дизайна ООП
У меня есть считывающая головка Первый Java, и я понимаю, как ООП работает. Вот моя проблема: я - PHP программист, и в то время как я использовал ООП в PHP, я испытываю затруднения при выяснении того, что должно быть объектом и что методы дать его.
Например, скажем, у меня есть приложение, которое позволяет людям входить в систему и редактировать документ. Почему документ должен быть объектом, если когда-либо только будет один экземпляр? Если я даю deleteDocument() метод к объекту документа или администраторскому объекту? Документ является удаляемым тем, но администратор является тем, выполняющим действие.
Таким образом, мой реальный вопрос, происходя из процедурной среды, как я выясняю то, что должно быть объектами и что должно иметь что методы?
7 ответов
Что ж, в вашем примере я не уверен, почему в вашем дизайне только один документ, но он все равно должен быть объектом на случай, если позже вы захотите больше одного.
Что касается функции удаления, на самом деле нет однозначного ответа; вы, вероятно, найдете аргументы с обеих сторон. Лично я бы поместил функциональность удаления нижнего уровня (например, удаление записей из базы данных) внутри класса документа, но любые другие функции могут передаваться в родительский. Если все документы принадлежат администратору, у администратора должен быть DeleteDocument, который вызывает удаление документа, а также удаляет все ассоциации из базы данных.
В общем, исходя из процедурных аспектов, если вы когда-нибудь обнаружите, что передаете большой массив переменных состояния или объявляете множество глобальных переменных, то превратите эту связанную функциональность в класс. Старайтесь, чтобы функциональность, содержащаяся в объекте, была как можно более тесно связанной, иначе вы можете обнаружить, что ваши классы выходят из-под контроля.
Это в некоторой степени будет зависеть от вашего выбора языка. Java - это «чистый объектно-ориентированный язык», что означает, что все должно быть упаковано в классы, нравится вам это или нет. C ++ «нечистый» - вы можете решить, что ваш документ будет просто набором глобальных переменных, если хотите.
Однако даже в C ++ вы часто будете упаковывать вещи в классы, даже если будет только один экземпляр. Это потому, что класс - это больше, чем просто способ упаковки произвольных вещей вместе - это механизм абстракции. Группируя связанные вещи вместе и давая имена группам, вы делаете свой код более читабельным и поддерживаемым - возможность повторного использования - главное преимущество, но не единственная причина использования класса.
DeleteDocument должен перейти к объекту администратора.
Вы используете его, потому что он менее бесполезен - и лучше Intellisense, более гибкий и т. Д. Кроме того, он имеет преимущества многопоточности.
Нет всегда верного ответа. Если вас интересует объектно-ориентированный дизайн, я рекомендую эту книгу .
Что касается вашего вопроса о том, как определить, какими должны быть объекты и какие методы они должны использовать, хорошая эвристика - спросить себя, важны ли какие-то способности для того, чтобы быть чем-то. Вот пример, который я помню из своего класса ООП ... Вы отслеживаете людей и домашних животных в приложении. Должен ли класс человека иметь метод getPets () ? Что ж, важно ли иметь домашнее животное, чтобы быть человеком? Нет. Лучшим решением может быть отдельный класс отношений, представляющий владение домашним животным.
Итак, мой настоящий вопрос, исходя из процедурного фона, как мне определить, какими должны быть объекты и какие методы должны быть у меня?
Имея Если вы получили некоторое представление о механике ООП от Head First Java, я бы порекомендовал вам теперь изучить несколько принципов хорошего ООП-дизайна. В сети есть много материалов, хороших и плохих, но если вам понравилась Head First Java, я рекомендую вам взять копию превосходного Head First OO Analysis & Design . Он ответит на многие ваши вопросы и содержит отличные примеры сценариев, подобных тем, которые вы здесь затронули.
После того, как вы разобрались с этим, вы, возможно, захотите взглянуть на принципы SOLID , а затем (как уже рекомендовал кто-то здесь) на некоторые общие объектно-ориентированные шаблоны проектирования .
Я бы посмотрел Как вы разрабатываете объектно-ориентированные проекты . Принятый ответ - хороший.
Шаги, которые я использую для первоначального проектирования (переход к диаграмме классов), следующие:
Сбор требований. Поговорите с клиентом и выделите варианты использования, чтобы определить, какие функции должно иметь программное обеспечение.
Составьте описание отдельных вариантов использования.
Просмотрите повествование и выделите существительные (человек, место, вещь) как классы-кандидаты и глаголы (действия) как методы / поведения.
Отбросьте повторяющиеся существительные и исключите общие функции.
Создайте диаграмму классов. Если вы Java-разработчик, в NetBeans 6.7 от Sun есть модуль UML, который позволяет создавать диаграммы, а также проектировать в оба конца, и это БЕСПЛАТНО. Eclipse (Java IDE с открытым исходным кодом) также имеет среду моделирования, но у меня нет опыта работы с ней. Вы также можете попробовать ArgoUML, инструмент с открытым исходным кодом.
Применяйте принципы OOD для организации ваших классов (исключая общие функции, выстраивайте иерархии и т. Д.)
"Документ" - это особый тип объекта - сущность. Тот факт, что он может быть сохранен или удален из хранилища, является отдельной проблемой, которая должна быть обработана другим классом в том, что некоторые называют "уровнем доступа к данным". Ваши бизнес-классы (надеюсь, они у вас есть) будут использовать сущность, dal и другие классы для выполнения ваших бизнес-функций.
Он выходит далеко за рамки этого, с введением интерфейсов и дженериков.