1

My colleague likes connecting OOP to how things work in the actual, but a bit too much and sometimes I believe in an awkward way.

Instance 1:
He always suggests not to use static variables to track all instances but create another class and then create an array in that class to do all that what could have been done using only a single static variable (of course with proper privileges). So, say I have a class called "Card", according to him I should not be using a static variable to track cards but have another class called "CardsList" and create an array inside this class "CardsList" to keep track of the cards.

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

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

vs

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

Instance 2:
If we were to create a simple stock market simulation.
I would prefer creating a class called market and store pending orders of that market in an array in that very class class market.
He on the other hand wants me to create a class named PendingOrders containing nothing but an array and doing nothing but what the array was doing in the class market. Something like this:

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

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

vs 

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

The answers he gives to reason his approach are completely useless, and I think he is blindly following what someone else had told him.

Can someone help me compare the two approaches? And when can one be more beneficial over the other?

Tuji J
  • 13
  • 2

2 Answers2

0

Encapsulating a list of objects in an instance of a class can be useful when passing the information around. If you later find out you need to add some more information, subclass it or replace what it looks like, you need not change the code that does the passing around.

Using static fields is often seen as an anti-pattern.

I think it's good that you come here looking for different ways to look at these options, but am a bit worried that you may have already dug in pretty deep in your arguments with your colleague. Try and come out of the trenches and look at things from both sides.

There's something to be said both for simplicity and for encapsulation. You'd expect encapsulation to pay off most in code bases that have to go though iterations of change, are maintained by more than one programmer and that may need to become more diverse and complex with time.

I think your question is quite broad and perhaps not best suited for a question and answer format like here. Reading up on OO programming may be a better way to get more insight on the reasons behind it and where (and where not) to apply it.

flup
  • 26,937
  • 7
  • 52
  • 74
0

static "variables" are an indication of code smell

static variables such as non-constant lists for storing class instances are akin to the singleton (anti-)pattern, which has a lot of stigma due to tightly coupling a class with a specific use-case for it, and therefore making it less reusable by design.

Why do static variables smell like the singleton pattern?

To elaborate on this comparison, if you think of the Card class itself as a value rather than a type (think of JavaScript and prototypal inheritance, i.e. "everything is an object"), reusing the class becomes difficult if there are multiple distinct uses of it where you want to keep track of only a specific subset of its instances rather than all of its instances, as this particular implementation would lock you into.

Using a separate class like CardsList for encapsulating storage of the Card class's instances is a good idea because it increases the reusability of the Card class should there be a need to keep track of multiple List<Card> and not just all instances of Card.

Examples of acceptable uses for static members

static members in object-oriented programming should be reserved for constant values, or methods which deal with the class in some way without referencing an existing specific instance of it. Other uses of static members should only be required in extreme cases where no other pattern can reasonably be applied, since it would tend to make the class less reusable.

In summary, if the proposed static member is not a method or a constant value, it's very likely to indicate an anti-pattern, or a code smell at best.

Patrick Roberts
  • 49,224
  • 10
  • 102
  • 153