ООП и масштабируемость

Question

Я читал статью на ibm.com/developerworks (сейчас не могу найти эту статью) о разработке масштабируемого программного обеспечения для облака.

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

Один пример был примерно таким:

class NonScalableCircle {
    int radius;

    void setRadius(int radius){
        this.radius = radius;
    }

    public integer getDiameter() {
        return 2*radius;
    }
}

Объяснение, почему это не было масштабируемым, было то, что вы должны сначала установить радиусзатем назовите диаметр.Таким образом, существует порядок для работы, потому что методы работают с одними и теми же данными.

Масштабируемый пример:

class ScalableCircle {
    public integer getDiameter(int radius) {
        return 2*radius;
    }
}

И, конечно, это правда.Весы без состояний намного лучше.Учитывая это и тот факт, что OBJECT = data + поведение, у меня следующие вопросы:

ООП просто не годится для приложений с высокой степенью параллелизма?ООП умрет и будет заменен процедурным программированием?

Потому что, даже в том виде, в каком оно существует сейчас, многие разработчики используют модель анемичной области и кодируют логику в сервисах.На самом деле ООП сделано немного.

Answer 1

Ответ - никто не знает. Пока нет особого понимания «правильного» способа написания последовательного программного обеспечения, а параллельное и параллельное программирование намного сложнее.

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

Answer 2

ООП умрет и будет заменен процедурным программированием?

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

То, что вы описываете в терминах безгражданства - это начало Монад

Начните возиться с Эрланг , чтобы увидеть, как вы масштабируете,правильно.

Разве ООП просто не подходит для высококонкурентных приложений?

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

Но у ООП все еще есть свое место, многие функциональные языки являются метаязыками и имеют ОО в них.

Другой метод достижения лучшего масштабирования - неблокирующий IO .

Другая проблема заключается в том, что многие корпоративные / бизнес-системы основаны на J2EE и .NET, которые на самом деле не поощряют методы масштабного масштабирования за пределами «купить больше серверов».

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

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

Answer 3

Хотя вы, безусловно, можете улучшить масштабирование на локальном уровне, удалив состояние, где это возможно, просто сказать «избавиться от состояния» мало что решает.Пользователь ожидает (и в основном нуждается) в том, чтобы все было в состоянии.

Эффективное масштабирование редко является вопросом избавления от состояния - это вопрос управления состоянием.Особенно в случае распределенных вычислений, это становится главным вопросом выяснения того, какое состояние должно быть реплицировано, на каких машинах они должны выполнять определенные части работы.

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

Вопреки распространенному мнению, функциональное программирование не обязательно является серьезным улучшением.Во-первых, FP не устраняет состояние (вообще).Это делает отдельные части состояния неизменяемыми, но это также не обязательно является существенным улучшением, поскольку может привести к простому удалению одной части состояния и замене ее чем-то «новым», имеющим то же имя, но другое значение.,В таких случаях неизменное состояние может быть различием без разницы.

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

В любом случае объекты разбиваются на довольно маленькиеидентифицируемые куски, которыми обычно довольно легко управлять.Отнюдь не усложняя распараллеливание и (особенно) распространение, это на самом деле делает это проще, если только код просто не 1013 * действительно плохо спроектирован.Конечно, ни один язык, парадигма, методология или многое другое не могут предотвратить плохой дизайн, но ОО предоставляет дизайнеру инструменты для хорошей работы и помогает существенно повысить практичность распределения и масштабирования.