Большинство из нас, если не все, для разработки больших приложений, для бизнес-приложений по большому счету, используют Domain Driven Design подход описанные Эриком Эвансом в 2004 году. Это способ проектирования, который фокусируется прежде всего на предметной области, на объектах реального мира, их поведении и взаимодействии, то есть фокусируется на модели и бизнес-логике
Т.е. у нас есть доменные объекты для данных и операций которые они могут выполнять, а так же доменные сервисы, для более комплексного взаимодействия объектов в них реализуется бизнес-логика.
При таком подходе используется уже классический принцип по определению того, что будет объектом (данными), а что действием. Существительные в описании предметной области будут объектами, глаголы – методами. Я думаю что большинство начинают именно с такого подхода, чтобы определить что вообще у нас есть из условий задачи. Дальше уже идет тюниг.
Рассмотреть пример кода, который должен быть понятен всем и который не вызывает проблем в понимании.
Привычный код с которым все более, менее привыкли работать.
Гораздо более ранним подходом, который мы используем является MVC.
Trygve Reenskaug (Тригве Рейнскау) представил MVC во время визита лаборатории XeroxParc в 1979 году. Вспомнив что сейчас 2012 год (я у кого-то удивление в глазах кажется увидел), можно сказать, что у Тригве было достаточно времени, для того чтобы проанализировать собственное изобретение и его применение, чтобы изобрести что-то новое. Да, да, именно этот человек предложил дальнейшее развитие в виде DCI.
Схематически любой похожий код можно представить в таком виде. Конечно это не строгий UML, но и так все понятно. Объекты, методы. Я думаю вы согласитесь, что это недалеко от правды.
Как они работают и взаимодействуют?
Да, тут они подсвечены цветом и можно примерно догадаться что с чем работает.
Вуаля! Пусть они взаимодействуют как на рисунках. Вот у нас два каких-то UseCase, как вы видите сильно отличных, но с одними и теми же объектами (они же классы).
Данное взаимодействие четче всего видно в run-time режиме.
Главная проблема такого кода отлично иллюстрируется следующим слайдом.
Как можно определить, что для чего использовать? В редакторе для нас весь код выглядит как на картинке. Все методы равноважны и имеют один и тот же приоритет в выполнении.
Если вернуться к коду, то очень легко можно уволить босса, или же самого себя отправить в отпуск. Компилятор ругаться не будет и не подскажет.
Однако же это не соответствует ментальной модели, которая находится в голове пользователя. Код позволяет сделать все, но это «все» может быть неверно. В run-time вы может не получите никакой исключительной ситуации, но по сути работа будет выполнятся не верно.
При модификации и изучении такого кода трудно понять связь элементов, что задумывалось изначально, не видно ментальной модели, которая натуральным образом возникает в голове пользователя.
42 – что это такое? Чем это может быть, как вы думаете?
Как вы видите, 42 может быть чем угодно, и уровнем в WoW и темературой за бортом, возрастом, длинной чего либо. Это может быт остаток на счете, и да, это универсальный ответ на все.
42 может быть чем угодно. Это объект. И возможности, а так же правила использования этого объекта будет ясно только из контекста использования.
Кстати, похожая проблема всегда возникает при переводе слов. Если реально хочешь помочь с переводом, всегда спрашиваешь контекст, в котором используется слово.