Я стараюсь не спорить о преимуществах / недостатках ООП или процедурного подхода, безразлично где.
Хочешь — рассматривай программу как множество функций. Хочешь — как множество объектов. Хочешь — вообще заморочься на аспектах. А ещё есть товарищ Шалыто и его конечные автоматы. Дело-то хозяйское.
Важно понимать, что парадигмы возникали не просто так. Появление ООП вызвано, не в последнюю очередь, укрупнением программ и усложнением их архитектуры. Сейчас же часто говорят о АОП, которое выносит сквозную функциональность в отдельную сущность, что может сильно экономить усилия человека.
Также, очень важно чётко определить цели твоей программы — от этого зависит, какая парадигма подойдёт. Если тебя волнует расширяемость — что ж, видимо тебе придётся познакомиться с ООП. Если скорость — то процедурный подход. Важно избежать фанатичной помешанности на одной парадигме.
После определения, в любом случае, не стоит забывать про рефакторинг (тут выскакивает Мартин Фаулер, и кричит — Нюхай свой код! Определяй запахи!). Больше всего рефакторинга в ООП, но и функции тоже можно рефакторить.
Дальше — больше: вспоминаются паттерны, которые представляют собой шаблонные методы обхода насущных проблем языка и решения архитектурных заморочек. Где паттерны — там GOF и Фаулер с POEAA. Затем всплывает TDD, с его написанием тестов перед написанием кода. Дальше — ещё больше, там будут горы непонятных аббревиатур и леса методологий.
На подобные темы писалось, пишется и будет писаться много.
Но нет серебряной пули.
Хочешь — рассматривай программу как множество функций. Хочешь — как множество объектов. Хочешь — вообще заморочься на аспектах. А ещё есть товарищ Шалыто и его конечные автоматы. Дело-то хозяйское.
Важно понимать, что парадигмы возникали не просто так. Появление ООП вызвано, не в последнюю очередь, укрупнением программ и усложнением их архитектуры. Сейчас же часто говорят о АОП, которое выносит сквозную функциональность в отдельную сущность, что может сильно экономить усилия человека.
Также, очень важно чётко определить цели твоей программы — от этого зависит, какая парадигма подойдёт. Если тебя волнует расширяемость — что ж, видимо тебе придётся познакомиться с ООП. Если скорость — то процедурный подход. Важно избежать фанатичной помешанности на одной парадигме.
После определения, в любом случае, не стоит забывать про рефакторинг (тут выскакивает Мартин Фаулер, и кричит — Нюхай свой код! Определяй запахи!). Больше всего рефакторинга в ООП, но и функции тоже можно рефакторить.
Дальше — больше: вспоминаются паттерны, которые представляют собой шаблонные методы обхода насущных проблем языка и решения архитектурных заморочек. Где паттерны — там GOF и Фаулер с POEAA. Затем всплывает TDD, с его написанием тестов перед написанием кода. Дальше — ещё больше, там будут горы непонятных аббревиатур и леса методологий.
На подобные темы писалось, пишется и будет писаться много.
Но нет серебряной пули.
