Должны ли объектно-ориентированные принципы применяться на процедурных языках?

Question

Я знаю, что в принципе возможно превратить даже процедурные языки, такие как C или MATLAB, в объектно-ориентированные. Этот вопрос довольно хорошо обсуждался здесь и здесь.

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

ПОЯСНЕНИЯ

Возможно, пример в порядке.

Я унаследовал некоторый код MATLAB, который реализует некоторый алгоритм машинного обучения. Там в основном одна функция building_model что, в зависимости от передаваемого флага, будет либо обучать модель, либо использовать ее для прогнозирования будущего значения:

building_model('train', ...) % ... stands for the data with which the model is trained

а также

value = building_model('predict')

Сама модель реализована с помощью постоянных переменных MATLAB внутри building_model,

Я разорвал на части building_model на две функции, одна для обучения и одна для прогнозирования. Модель, которая раньше была реализована как постоянные переменные, теперь, так сказать, внешне:

model = new_model()
model = model_train(model, ...)
prediction = model_predict(model)

Это, грубо говоря, насколько мне удалось эмулировать некоторые функции ООП в MATLAB. Мой модуль модели здания теперь действует как класс, с конструктором и двумя методами model_train а также model_predict, Я достиг некоторой степени инкапсуляции (хотя ничто не мешает вызывающей стороне возиться с внутренностями model), и полиморфизм в принципе тоже можно учесть. В качестве дополнительного бонуса я получаю разделение команд / запросов практически бесплатно, так как model_predict не возвращается modelи, следовательно, не может изменить model,

(Проницательные читатели отметят, что в MATLAB уже есть объектно-ориентированная система. По разным причинам, включая производительность и совместимость со старыми версиями, я не могу ее использовать.)

Я мог бы представить себе подобный механизм в C, где вы разработали бы некоторую структуру данных и напишите функции, первый аргумент которых был бы экземпляром этой структуры данных.

То, что я хотел бы знать, насколько далеко я могу продвинуть этот способ программирования? Это общепринятый образец (там, я сказал слово)? Есть ли какие-то проблемы с производительностью, на которые мне следует обратить внимание?

Answer 1

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

Я думаю, что Common Lisp является хорошим примером. У него действительно хорошая ООП-система (CLOS), которая, я бы сказал, действительно завершена. Но, тем не менее, ООП не так широко используется в Common Lisp, как в Python или C++, поскольку это удобная функция, а не то, что необходимо для обеспечения базовых блоков разработки программного обеспечения.

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

Answer 2

Объектная ориентация является средством для достижения целей разработки программного обеспечения.

Цель: простота обслуживания, расширяемость, организованный исходный код (возможность поиска и т. Д.)
OO Construct: инкапсуляция (только данные, принадлежащие "типу / структуре данных", могут работать с его данными)

Цель: возможность разработки новых функций без изменения существующих, повторное использование кода
ОО Construct: реализация наследования, полиморфизм

Цель: абстракции (вам не нужно фиксировать определенный тип или операции, изменение реализации без изменения клиентов)
OO Construct: наследование интерфейса, интерфейсы, абстрактные классы

Цели не нуждаются в обосновании. Хотите ли вы / нуждаетесь в поддержке языка OO или нет - это зависит от вашей конкретной ситуации. Если вам нужно использовать C, вы все равно можете имитировать некоторую OO-конструкцию и, надеюсь, воспользоваться ее преимуществами.

Имейте в виду, что абсолютно возможно разработать беспорядок кода с соблюдением всех принципов ОО.

Я уверен, что другие могут перечислить другие цели и примеры (и знать, как редактировать таблицы в сообщениях stackru)