Atomic или Гигантский

Question

Если вы планируете написать очень параллельное применение в C#, что лучше строить вещи очень мало, как

20 небольших классов, что делает 40 больших классов, а вместе сделать 60 более, для в общей сложности 120

или гигантский, как:

делает эти 60 классов по отдельности (по-прежнему с учетом возможности повторного использования).

Итак, в # 2 эти 60 классов могут содержать методы, позволяющие делать что-то, а не другие классы.

Answer 1

Меньшие кусочки легче тестировать, проще рефакторировать и просты в обслуживании.

Answer 2

Таким образом, ни один из этих подходов не изменит ситуацию.

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

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

Answer 3

Это не размер классов, но важна область действия муфты.

Для параллельных приложений вы должны использовать неизменяемые объекты, которые иногда называются «объектами ценности», а не объекты с большим количеством свойств. Если вам нужно применить операции, которые приводят к новым значениям, просто создайте в результате новые объекты.

Соблюдайте хорошее разделение проблем, и пусть это приведет вас к естественному количеству классов для представления концепций в вашей программе. Я рекомендую принципы SOLID, каталогизированные и популяризированные Робертом Мартином из ObjectMentor. (Этого должно быть достаточно Google-фуража, чтобы найти список!)

Наконец, я также рекомендую вам познакомиться с System.Threading и System.Collections. Большинство коллекций по сути не являются потокобезопасными, а синхронизация, как известно, трудно получить. Таким образом, вам лучше использовать широко используемые, проверенные, надежные примитивы синхронизации.