Непосредственное использование массива против создания другого класса для хранения того же массива (совет по выбору дизайна)

Question

Моему коллеге нравится связывать ООП с тем, как все работает на самом деле, но немного слишком, и иногда я неуклюже верю.

Экземпляр 1:
Он всегда предлагает не использовать статические переменные для отслеживания всех экземпляров, но создать другой класс, а затем создать массив в этом классе, чтобы делать все то, что можно было сделать, используя только одну статическуюпеременная (конечно, с соответствующими привилегиями).Итак, скажем, у меня есть класс с именем «Card», по его словам, мне не следует использовать статическую переменную для отслеживания карт, но есть другой класс с именем «CardsList» и создание массива внутри этого класса «CardsList» для отслеживания карт..

//in the main class  
private CardsList Cards = new CardsList(); 

//in CardsList class
static List<card> CardsList = new ArrayList<>();

против

//in the cards class
static List<card> CardsList = new ArrayList<>();

Экземпляр 2:
Если бы мы создали простую симуляцию фондового рынка.
Я бы предпочел создать класс, называемый market и storeотложенные ордера этого рынка в массиве этого класса.
С другой стороны, он хочет, чтобы я создал класс с именем PendingOrders, не содержащий ничего, кроме массива, и ничего не делающий, кроме того, что массив делал на рынке классов.Примерно так:

//in the market class    
private PendingOrders pendingOrders = new PendingOrders();

//in the PendingOrders class
private List<order> pendingOrders = new ArrayList<order> ();

против

//in the market class
private List<order> pendingOrders = new ArrayList<order> ();

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

Может кто-нибудь помочь мне сравнить два подхода?И когда один может быть более выгодным по сравнению с другим?

Answer 1

static «переменные» являются признаком запаха кода

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

Почему переменные static пахнут как шаблон синглтона?

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

Использование отдельного класса, такого как CardsList, для инкапсуляции хранилища экземпляров класса Card - хорошая идея, потому что это увеличивает повторное использованиеспособность класса Card в случае необходимости отслеживать несколько List<Card>, а не только все экземпляры из Card.

Примеры допустимого использования для staticчлены

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

---

В целом, если предлагаемый *Элемент 1034 * не является методом или постоянным значением, он, скорее всего, указывает на анти-шаблон или запах кода в лучшем случае.

Answer 2

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

Использование статических полей часто рассматривается как антишаблон .

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

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

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