Вы рекомендуете разработку программного обеспечения процедурной методологии для небольших приложений баз данных в точечной сети?

Question

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

Когда я начинаю разработку, я хочу использовать объектно-ориентированную парадигму дизайна для любого приложения. Для начала я начну с небольшого проекта по разработке баз данных, такого как управление гостиницей, расчет заработной платы, продажа приложений и т. Д. Тем не менее, в моем курсе, когда я искал в Интернете исходные коды, я обнаружил, что многие программисты разрабатывают свой исходный код в Интернете процедурным способом для такого типа небольшого приложения. Хотя они используют vb dot net или C # (ориентированные на языки), они пытаются следовать процедурным принципам, например, определяя все глобальные методы и переменные в одном классе, а затем вызывают метод доступа из определенной формы для определенного действия.

например. для приложения управления библиотекой дизайн может выглядеть следующим образом

   //one global class for whole method and variable definition
Class globals {
//define  public variable and public function such as
//connection to db code
Public  void storebooks() 
{//code for storing books to db
}
Public  void  storeusers
{ //code for storing users to db
}
.
.
//code for searching books  …etc
}

Затем форма использует определенный глобальный метод и переменную для своей работы, точно так же, как объявление модуля в vb6.

Мой вопрос: когда я пытаюсь сделать приложение, которое я пытаюсь сделать, используя oop методологию, определяя объект класса, атрибуты… и т. Д. Так я в правильном направлении? Должен ли я разрабатывать приложения такого типа, используя методологию с возражением (хотя и небольшую), или я должен придерживаться приведенного выше кода типа, который я нашел в Интернете (процедурный способ)?

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

Спасибо

Answer 1

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

Причина может быть в том, что программист просто приходит из неOO языка, такого как C, и пытается адаптировать свои знания к новому языку.Может также оказаться, что приложение настолько простое, что процедурный подход подходит лучше всего.

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

Написать приложение на чистом ОО не так просто, как кажется.Особенно узнать вашу модель домена (на которой вы основываете дизайн своего приложения) может быть сложно.Но если у вас есть эта модель в моем опыте, то довольно легко создать ОО-приложение, маленькое или большое.Конечно, очень важно знать все потоки (варианты использования, процессы / процедуры (!)), Чтобы иметь возможность определять отношения в вашей модели.

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

Чтобы сделать этот длинный рассказ коротким: проясните для себя природу ОО и природу других парадигм и подумайте, что лучше дляприложение, которое вы хотите построить.В качестве практики вы можете также создать приложение как OO, так и процедурно, и посмотреть, что вы можете из этого извлечь.

Говоря о себе, я почти всегда использую OO для приложений на C # (или Java), также простых.Глубина модели варьируется также в зависимости от сложности и ремонтопригодности.Обычно я делаю прототипы с несколькими вариантами, и после этого решаю о моем окончательном дизайне (совет: всегда рисуйте / проектируйте свои модели!).Тем не менее, я не верю, что парадигма ОО подходит всем.

Answer 2

Хотя дискуссия «ООП и процедурное программирование» все еще жива, я сомневаюсь, что для такого маленького проекта был взят реальный методологический анализ.

Многие программисты, которые выполняют простые проекты ERP, имеют процедурный фон (Visual Basic <= 6 или даже COBOL) и не совсем понимают объектно-ориентированную модель. Поэтому они используют ОО-языки как своего рода «компонентно-ориентированную» систему (то есть они используют готовые объекты только для графического интерфейса, а не для логики программы). </p>

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

Answer 3

Отличным ресурсом для рассмотрения процедурной разработки, переходящей в объектно-ориентированное проектирование, является книга Wrox Publishing под названием " Refactoring in Visual Basic ".

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

Хотя эта книга не являетсяОбязательный обзор различных стратегий и реализаций разработки, он отлично справляется с противопоставлением различных методов итеративным процессом рефакторинга.