Клиентский код в итоге пишется в процедурном стиле?

Question

[NikolayAlb]

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

- Возьмем для примера любой шаблон проектирования. В большинстве случаев он будет сильно опираться на конечную клиентскую реализацию, если брать стратегию - выбор и реализация стратегии происходит во входном клиентском коде, т.е. всё ООП происходит непосредственно "после/перед" клиентским кодом, где происходит процедурка.
- Попробую привести другой пример, возьмем общую архитектуру MVC, в большинстве случаев клиентом здесь будет являться контроллер (замечу, что контроллер в данном случае - именно основа логическая, а не системная) - именно он определяет базовое поведение и алгоритм работы того или иного "модуля", и опять-же, в контроллерах пишется тот-же процедурный код.
- Также, если брать для примера даже базовые концепции, типа полиморфизма - здесь опять-же вступает процедурка из клиента, которая и определяет конкретные реализации.

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

Правильно ли я понимаю ситуацию, или нет?

Answer 1

[Stalker_RED]

Смешались в кучу кони, люди...

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

Паттерны (шаблоны проектирования же) нужны для того, чтобы объяснить ДРУГИМ ПРОГРАММИСТАМ что за хрень мы тут написали.
Можно писать код, который вообще ни на что не похож и не соответствует никаким шаблонам. И тем людям, которые захотят разобраться в коде вынуждены будут его прочесть целиком и осмыслить. Или мы пишем: здесь у нас шаблон "наблюдатель" а вот нам у нас singleton и всем сразу понятен общий смысл.

С MVC пример не особо удачный. Дело в том, что сейчас существует довольно много разных штук на которые почему-то прилепили буковки MVC, хотя на самом деле... В целом понятно, что вы пишете о случае с "толстыми контроллерами" но ведь может быть несколько разных контроллеров которые работают с одной моделью.
И могут быть разные модели, отдающие данные в одно и то-же представление. Но об этом ниже.

И с полиморфизмом вы что-то напутали. Посмотрите хоть в википедии что это и зачем. Клиентов ведь может быть больше одного. Сегодня наш код работает на телефоне с ios, завтра на andoid'е, а послезавтра на голографическом телевизоре с пси-управлением. И данные он вчера брал из MSSQL а сегодня берет из mongodb. Но при этом у нас все круто спроектировано, и мы не меняем ядро приложения. Только подсовываем новые реализации интерфейсов по необходимости. Вот про что полиморфизм.

Comments

[stratosmi]

Вот я юзаю метод Billng.getUserBalance() и не задумываюсь что там внутри этого getUserBalance()

Немного некорректно.
То, что описали вы - оно и в процедурном стиле так же.
"Не задумываюсь что внутри объекта Billing" - вот это лучше характеризует ООП.

Answer 2

[Griboks]

Вы смешали код и его организацию. Вы можете взять функцию y=x*2+1 и записать её как процедуру. Можете записать как композицию функций, как поток, как абстракции, как класс, как монаду... В любом случае, вы по-разному организуете один и тот же алгоритм.

P. S.
На самом деле, любой код декларативный.

Comments

[stratosmi]

код декларативный.

Наоборот - большинство языков программирования общего назначения - императивны.
Как только вы добавили в программу первый IF....
А к декларативным относится малая их часть. Например, SQL (без PL/SQL) или HTML (который, строго говоря, даже не язык программирования).

[Griboks]

stratosmi, но любой язык транслируется в ассемблер, а он декларативный.

[stratosmi]

Griboks, ассемблер - чисто императивный. на 100% императивен.

и, да - НЕ транслируется любой язык в ассемблер. только некоторые - так как это не обязательное условие.
а в машинный код в конечном итоге.

Answer 3

[Inside89]

Или я чего-то не догоняю или вам нужно лучше по изучать терминологию программирования, фраза:
"- Попробую привести другой пример, возьмем общую архитектуру MVC, в большинстве случаев клиентом здесь будет являться контроллер"
Клиентом является front end, сервер это back end, Контролер это класс подключаемый к ядру нашей программы с набором базовых методов и свойств, и потом уже мы наследуемся от этого класса для создания расширения нашей программы дополняя новыми методами и свойствами взаимодействуя с наследуемым классом модели, формируя массив данных даем ответ в наш шаблон.
Соответственно Класс Модель содержит основную логику запросов к базе данных, далее так же наследуясь от него мы расширяем наш функционал.
Тем самым наши действия разложены по полочкам, имеет древовидный характер взаимодействия, и следовательно читать код и расширять намного эффективнее монолитного процедурного хаоса, где после несколько лет расширения, даже самый ярый тру кодер сломает себе мозг. Много написал очевидных вещей про MVC, но это так к слову для общей картины, да и кому-то будет полезно.