Клиентский код в итоге пишется в процедурном стиле? Активно изучаю и переосмысливаю ООП, паттерны, принципы и другие основы программной архитектуры. И поймал себя на мысли, что в итоге в основной/конечной точке программы мы все равно работаем в процедурном стиле. Возможно я где-то ошибся в терминологии, поэтому объясню, что я имею в виду дальше.
- Возьмем для примера любой шаблон проектирования. В большинстве случаев он будет сильно опираться на конечную клиентскую реализацию, если брать стратегию - выбор и реализация стратегии происходит во входном клиентском коде, т.е. всё ООП происходит непосредственно "после/перед" клиентским кодом, где происходит процедурка.
- Попробую привести другой пример, возьмем общую архитектуру MVC, в большинстве случаев клиентом здесь будет являться контроллер (замечу, что контроллер в данном случае - именно основа логическая, а не системная) - именно он определяет базовое поведение и алгоритм работы того или иного "модуля", и опять-же, в контроллерах пишется тот-же процедурный код.
- Также, если брать для примера даже базовые концепции, типа полиморфизма - здесь опять-же вступает процедурка из клиента, которая и определяет конкретные реализации.
Определенно, во всех вышеперечисленных примерах я слишком громогласно использую понятие "процедурный/ка", я имею в виду более локализированное и упрощенное понятие - что-то типа последовательного/процедурного алгоритма.
Правильно ли я понимаю ситуацию, или нет?
Клиентский код в итоге пишется в процедурном стиле? Активно изучаю и переосмысливаю ООП, паттерны, принципы и другие основы программной архитектуры. И поймал себя на мысли, что в итоге в основной/конечной точке программы мы все равно работаем в процедурном стиле. Возможно я где-то ошибся в терминологии, поэтому объясню, что я имею в виду дальше.
- Возьмем для примера любой шаблон проектирования. В большинстве случаев он будет сильно опираться на конечную клиентскую реализацию, если брать стратегию - выбор и реализация стратегии происходит во входном клиентском коде, т.е. всё ООП происходит непосредственно "после/перед" клиентским кодом, где происходит процедурка.
- Попробую привести другой пример, возьмем общую архитектуру MVC, в большинстве случаев клиентом здесь будет являться контроллер (замечу, что контроллер в данном случае - именно основа логическая, а не системная) - именно он определяет базовое поведение и алгоритм работы того или иного "модуля", и опять-же, в контроллерах пишется тот-же процедурный код.
- Также, если брать для примера даже базовые концепции, типа полиморфизма - здесь опять-же вступает процедурка из клиента, которая и определяет конкретные реализации.
Определенно, во всех вышеперечисленных примерах я слишком громогласно использую понятие "процедурный/ка", я имею в виду более локализированное и упрощенное понятие - что-то типа последовательного/процедурного алгоритма.
Правильно ли я понимаю ситуацию, или нет?
- Возьмем для примера любой шаблон проектирования. В большинстве случаев он будет сильно опираться на конечную клиентскую реализацию, если брать стратегию - выбор и реализация стратегии происходит во входном клиентском коде, т.е. всё ООП происходит непосредственно "после/перед" клиентским кодом, где происходит процедурка.
- Попробую привести другой пример, возьмем общую архитектуру MVC, в большинстве случаев клиентом здесь будет являться контроллер (замечу, что контроллер в данном случае - именно основа логическая, а не системная) - именно он определяет базовое поведение и алгоритм работы того или иного "модуля", и опять-же, в контроллерах пишется тот-же процедурный код.
- Также, если брать для примера даже базовые концепции, типа полиморфизма - здесь опять-же вступает процедурка из клиента, которая и определяет конкретные реализации.
Определенно, во всех вышеперечисленных примерах я слишком громогласно использую понятие "процедурный/ка", я имею в виду более локализированное и упрощенное понятие - что-то типа последовательного/процедурного алгоритма.
Правильно ли я понимаю ситуацию, или нет?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Ваша мысль имеет право на существование, но не совсем точна. Действительно, клиентский код часто содержит последовательности вызовов функций и методов, что может напоминать процедурный стиль программирования. Однако, в случае использования принципов ООП и шаблонов проектирования, клиентский код все равно взаимодействует с объектами, работает с абстракциями и интерфейсами, а не только с конкретной реализацией.
Таким образом, ООП предоставляет инструменты для более гибкой и инкапсулированной реализации программных систем, позволяя лучше разделять ответственности между объектами и повышать уровень абстракции. При правильном применении ООП и шаблонов проектирования клиентский код может оставаться структурированным и поддерживаемым, несмотря на некоторые черты процедурного стиля.
Таким образом, необходимо помнить, что ООП и процедурное программирование все же имеют свои отличия, и правильное применение принципов ООП дает возможность создавать модульные, расширяемые и поддерживаемые системы.