И в зависимости от задачи многие концепции становятся отдельными объектами в программном обеспечении.
Подумайте об объектах.
Вокруг нас все объекты.
Почему вы должны использовать объекты для представления вещей в вашем коде?
Это способ держать ваш код организованным, гибким и многоразовым.
Объектный подход создает организованный код, содержа связанные детали и конкретные функции в разных, легко доступных местах.
Это создает гибкость, поскольку вы можете легко изменять детали модульным способом, не затрагивая остальную часть кода. Также вы можете повторно использовать разные части кода.
Давайте рассмотрим, как может выглядеть объектно-ориентированное моделирование.
Рассмотрим, например, помещение для семинаров.
Первый объект, который мы идентифицируем, является сама комната.
В комнате есть такие детали, как номер комнаты и места для сидения.
Также мы можем идентифицировать объекты, которые содержатся в этой комнате.
Существует множество физических объектов, такие как стул, стол, проектор и белая доска.
Каждый из этих физических объектов может быть представлен объектами в программном обеспечении.
И существуют конкретные детали, связанные с каждым объектом.
Проектор имеет характеристики, связанные с его производительностью, такие как разрешение и яркость.
И объекты также могут иметь индивидуальные обязанности или поведение.
Например, проектор принимает видеопоток и отображает изображение.
Вы можете думать о разработке программного обеспечения как о процессе, который берет задачу и создает решение с помощью программного обеспечения.
И как правило, это итеративный процесс, при этом каждая итерация берет набор требований для реализации и тестирования и в конечном итоге создается полное решение.
Многие разработчики стремятся сразу кодировать, несмотря на то, что не полностью понимают, что программировать в первую очередь.
И погружение прямо в работу по реализации является основной причиной отказа проекта.
Если вы не хотите, чтобы ваши проекты потерпели неудачу, найдите время, чтобы сформировать требования и создать дизайн.
Вы не можете сделать их идеальными, но их важность для эффективного создания хорошего программного обеспечения не следует упускать из виду.
Выявление требований требует активного изучения видения клиента, задавая вопросы о проблемах, которые клиент, возможно, не рассмотрел.