5

Given the classes:

public class SocialNetwork
{
    private final Map<String, User> users;
    ...
}

public class User
{
    private final String user;
    private final LinkedList<String> followers; //stores the users that "user" follows
...
}

I was wondering if it is considered a good design practice (and why) to store the user's name in "followers" (username is unique and can't be changed) and retrieve the reference to the object through the "users" hashmap - as in the example above - or to store the object of the "User" class directly in "followers" - as in the example below?

//EDIT: I modified this example to make it less ambiguous
public class SocialNetwork
{
    private final Map<String, User> users;
    ...
}
public class User
{
    private final String user;
    private final LinkedList<User> followers; //stores the users that "user" follows
    ...
}
1
  • 1
    Both approaches are okay in different situations. For example, you probably only want to store the name if the object is going to be serialized.
    – John Wu
    Jan 1 at 21:43

3 Answers 3

7

Using references to other objects, has the advantage of using OOP spirit and ensuring very fast navigation. But it requires all related objects to be in memory. And this is a very hard constraint for many real life applications:

  • performance constraint: you need to upload thousands of related users and posts (even very old and unrelevant ones), just for consistency, because you want to get a single user.

  • complexity constraint: you may need to upload objects in several passes in a specific order to avoid cycles and inconsistencies.

  • distribution constraint: references only work on a single machine in a single process. This is a hard limit to scalability if you manage complex object structures that need to be distributed on many nodes, or if you adopt a microservice architecture.

For these reasons, storage of the ID of related objects is a very common practice. It's supported by patterns such as the identity map and repository pattern. It is even recommended between aggregates in DDD (entities within one and the same aggregate could however reference each other since consistency is managed at aggregate level and may probably require most of them to at the same time).

1

In O.O.P. references / pointers are preferred to the most imperative / procedural index usage, since it's more related to the O.O. paradigm ( "way to solve things" ).

Yet, in some circumstances, indices or text keys may be used, depending on the requirements, like an array collection, or a text dictionary collection.

0

The only OO paradigm i know is, that objects can care for their own needs.

Why not use both and let the object decide, which applies best? Initially, you only store the user name and leave the reference empty. First time, the object is used, it finds the reference empty and can retrieve the user reference. So, you only need to fetch the reference once. And you only need to fetch references that are really needed.

2
  • Are you referring to the "followers" list or to the "users" hashmap?
    – QenBau
    Jan 4 at 10:20
  • 1
    I think it´s worth to use both. Storing a string list will be slower, as you have to retrieve the object reference every time you want to access the user. But you can add an empty list of references as a buffer, so you only have to get the reference once. Next time, you can use the reference from the buffer. That would be a typical OOP-way to solve this issue. It is no uncommon that OOP sometimes wastes a bit of memory or has some internal redundancy to get things done.
    – Eckehard
    Jan 4 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.