ОО или процедурный - PullRequest
       79

ОО или процедурный

5 голосов
/ 18 июля 2009

У меня есть база данных Access, которую я использую для своей чековой книжки (с хорошим количеством довольно простого VBA за ней), и я хотел бы переписать ее как отдельную программу с SQL-сервером. Я думаю об использовании C ++, Java или Python.

До того, как начать, я предполагал, что напишу это ОО, потому что думал, что буду думать «в терминах ОО» (из-за класса ОО-логики и класса С ++, который я выбрал), но я нахожу Я могу только визуализировать это как процедурный (но, возможно, потому, что я мысленно застрял в размышлениях о том, как БД работает в Access). Как мне решить? Имею ли я смысл или кажется, что я не понимаю концепции?

Спасибо за вашу помощь.

Ответы [ 7 ]

5 голосов
/ 18 июля 2009

Я бы предложил ОО - это не сложнее, чем процедурное программирование, на самом деле его легче поддерживать с помощью правильного инструмента. Delphi будет моим выбором - отличная поддержка программирования БД, визуальный конструктор, строгий тип, множество доступных компонентов. Есть много замечательных приложений, написанных на Delphi . Часто недооценивают, есть много причин, по которым у него есть верные последователи.

Теперь я буду нырять, когда ненавистники Дельфи будут загружаться помидорами.

1 голос
/ 18 июля 2009

Ну, ОО может быть излишним, но это отличная практика. Любой код обезьяны может написать процедурный код. Это путь наименьшего сопротивления в каждом случае, поэтому большинство людей используют его для одноразовых приложений, которые мало что делают. Однако, если вы пишете, чтобы получить опыт работы с ОО, лучше подумать об этом. Вы можете начать с проектирования объекта, который управляет финансовой транзакцией, тогда вам также понадобится способ взаимодействия с БД. Возможно, вы могли бы написать слой БД, в котором вы абстрагируете вызовы базы данных от объекта транзакции, используя среду Entity, где вы могли бы изучить LINQ (или любой другой эквивалент JAVA). Все это при условии, что вы делаете это для развлечения и практики.

0 голосов
/ 19 июля 2009

Если вы ищете быстрое приложение, которое можно расширить, проверьте Динамические данные .

0 голосов
/ 18 июля 2009

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

Что вы должны сделать, это написать тесты , модульные тесты, а затем интеграционные тесты. И вы должны стремиться писать тесты в первую очередь. Таким образом, даже если вы начнете с процедурного приложения, вы можете позднее преобразовать его в полноценное ОО-приложение. Но только если вам нужны предметы. Эти тесты станут вашей надежной защитой при перемещении кода в вашем приложении.

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

Я не гений, поэтому я могу ошибаться, но по моему опыту лучше начинать с простых функций, а затем думать о группировании их в объекты или модулей лучше, чем начинать словами: "ОК У меня будет этот объект, который взаимодействует с этим объектом, который реализует шаблон X, поэтому таким образом я отделю интерфейс Y от реализации Z. Позже вы можете заметить, что ваша модель предметной области слаба. Выберите эволюционный путь проектирования и начните с небольших строительных блоков.

0 голосов
/ 18 июля 2009

Я бы пошел с Python: без компиляции и использует динамическую типизацию (вы также можете использовать строгую типизацию, если хотите). Кроме того, у него есть огромное количество поклонников в сообществе открытого исходного кода, что означает бесплатную поддержку, инструменты и документацию.

Что касается ОО против процедурного - все упомянутые вами языки могут быть написаны в процедурном стиле - то есть один большой класс / метод, который делает все - но вы скоро обнаружите, что хотите следовать принципам СУХОЙ (не повторять себя) и начать с некоторых частных методов, которые хорошо выполняют одну конкретную вещь. С этого момента вы захотите сгруппировать подобные вещи в отдельные классы, а затем оттуда вы захотите абстрагировать эти классы ... видите, куда я иду?

0 голосов
/ 18 июля 2009

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

0 голосов
/ 18 июля 2009

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

...