If any of those objects can be null, then you have to check for null before calling a getter on this object, of course.

But this kind of chaining is a bad smell of a lack of encapsulation (anemic objects having just data, and no behavior). You're violating the law of Demeter : don't talk to strangers.

Should I be nesting one object as part of another or should I be creating more specific objects for different usages.

1. Follow OO principles first which means "more specific objects." In doing so your classes may "line up" with your database schema or not but do not let DB schema trump good OO design.

2. Single Responsibility Principle will help guide you in what classes to build. SRP means, for example, that a Song is a song. It is not an artist, it is not a list of subscribers, so it should not have artist or subscriber stuff in it. Only song stuff.

3. The above means that you will have lots of small, independent, fully functional things - classes. By "fully functional" I mean, if a Song is a name, date, and id then that's what's in it. period. The fact that a certain artist sings that song does not inherently, fundamentally define what a Song is. This means other classes to model relationships like "an artist's song repertoire" for example.

4. Small functional classes leads to good DAO's and flexibility for your user interface.

Option 1 means wasting a lot of time/resources grabbing information I may not need for that page but easier to manage. Option 2 is messy and requires keeping track of which object is what but faster and far less db calls

1. You are falling victim to premature optimization. How can you know up front that option 2 will have "fewer DB calls?" What does that mean anyway?

2. This is simply the wrong way to think about your domain classes/model. This is why you end up duplicating your DB schema:

.

Class SongWithArtist {
  private $song; //Basic Song object
  private $artist; //Basic Artist object
}

When what you should have is something describing the real world:

Class ArtistPortfolio {
    private Artist $theArtist;
    private List<Song> $portfolio;  // list of songs (s)he sings 
}

Class ArtistSubscribers {
    private Artist $theArtist;
    private List<User> $subscribers;  // list of people who like this artist
}

// And it would probably make sense to combine the above 2 classes:

Class ArtistProfile {
    // an Artist object, not just an id. We're doing OBJECT oriented programming.
    private Artist $theArtist;

    private List<Song> $portfolio;  // list of Song objects 
    private List<User> $subscribers; // list of User objects
}

// and if you need a list of profiles...
Class ArtistProfiles {
    private List<ArtistProfile> $profiles; // a list of type ArtistProfile

    public ArtistProfile GetProfileByArtist (Artist thisArtist){}
    public ArtistProfile GetProfileByName (string name) {}
    public ArtistProfile GetProfileById (string id) {}
}

// I'd say a ArtistProfile could be part of an Artist..

Class Artist {
    private $id;
    private $name;
    private ArtistProfile $profile; // this is composition.
}


//In lieu of the above, an DAO oriented Artist composition ...
// Just go with the refactoring flow!
Class Profile {
    private $id;
    private $name;
    private $birthdate
}

 Class Repertoire {
    // a Profile object, not just an id. We're doing OBJECT oriented programming.
    private Profile $theArtist;

    private List<Song> $portfolio;  // list of Song objects 
    private List<User> $subscribers; // list of User objects
}

Class Artist {
    private Profile $me;
    private Repertoire $myStuff; 
}

Too Many DB Calls!

NOT. You can instantiate a Artist object without populating the $myStuff and in turn, defer populating $subscribers / portfolio lists until needed. This is called lazy loading.

While you are absolutely right with your answer, here are few more details about it.

The thing you are talking about is actually Containment or HAS-A relationship. There are two types of containments in OOP.

Consider A HAS-A B

Composition: It is a type of containment where B cannot exist if A dies. Best example is a House has-a room. If house is destroyed, room has no existence.

Aggregation: It is a type of containment where B can still exist even if A dies. Example for this is Employee has-a department. Even if employee is destroyed, the department will still exist

Well, I imagine you'd have a Service class and a Map of them which is keyed on the service name:

class Service {
    private String name, password;

    public Service(String name, String password) {
        this.name = name;
        this.password = password;
    }

    // getters, setters if you'd like
}

Map<String, Service> services = new HashMap<>();
services.put("pandora", new Service("ziggy", "stardust"));
// etc.

Of course there will be some significant differences between the two given the loosely-typed nature of JS and Java's strict typing.

Both Component and Container can contain components. If they offer the same methods for adding/removing etc., they should inherit from a common ancestor:

public class ComponentHolder {
    List<Component> components;
}

public class Component extends ComponentHolder {
    // ...
}

public class Container extends ComponentHolder {
    String containerName;
    // ...
}

EDIT: Another possibility would be to use composition. That way your classes wouldn't need a common ancestor, but would still use the same component-list implementation. If you decided to change the way components are stored, you would do it in one place only.

public class ComponentHolder {
    List<Component> components;
    // add, remove, get, ...
}

public class Component {
    ComponentHolder content;
    void add(Component c) {
        content.add(c);
    }
    // ...
}

public class Container {
    String containerName;
    ComponentHolder content;
    // ...
}

You will need recursion. Iterate over all the persons in the List and search within that person for the same target. Once you found your target, return and stop all searching.

Here is some pseudo code:

Person search(Person, Name)
    if (Person.Name == Name) return Person;
    for each subPerson in Person.person:
        Person found = subPerson.search(Person, Name);
        if (found != null) return found;
    return null;

It's somewhat easy if all of your fruit implement a common interface. It's a lot more difficult if they don't, to the point where I'd probably suggest using another language altogether. Java's not suited for that.

If they implement a common interface, you can use Class.forName to get the class, and then getConstructor to be able to instantiate the objects:

Basic interface (yours would probably declare more useful behaviour) :

public interface Fruit {
    String getName();
}

Apple:

public class Apple implements Fruit {
    private final Fruit child;

    public Apple(final Fruit child) { this.child = child; }

    @Override
    public String getName() {
        return "I am an apple " + (child == null ? "" : child.getName());
    }
}

Banana can be basically identical to Apple, just with a different name.

Strawberry:

public class Strawberry implements Fruit {
    @Override
    public String getName() {
        return "I am a strawberry";
    }
}

Main method is below. We need to iterate in reverse through the array in order to build the child objects first.

@SuppressWarnings("unchecked")
public static void main(final String... args) throws Exception
{
    String[] splitted = {"Apple", "Banana", "Strawberry"};
    Fruit prevFruit = null;
    for (int i = splitted.length - 1; i >= 0; --i)
    {
        final String className = splitted[i];
        final Class<? extends Fruit> clazz = (Class<? extends Fruit>) Class.forName("my.pckage." + className);
        if (prevFruit == null) // if first, use no-arg constructor
        {
            prevFruit = clazz.getConstructor().newInstance();
        }
        else
        {
            prevFruit = clazz.getConstructor(Fruit.class).newInstance(prevFruit);
        }
    }
    System.out.println(prevFruit.getName());
}

Sample output:

I am an apple I am a banana I am a strawberry

Collections can be initialized at definition point

public class RootNode {
    public Set<ShiftDate> shiftDateSet = new HashSet<>();
}

public class ShiftDate {
    public LocalDate date;
    public Set<Location> location = new HashSet<>();
}

public class Location {
    public Set<ShiftType> shifts = new HashSet<>();
}

This way when calling the RootNode constructor

RootNode rootNode = new RootNode();

It will initialize every nested object initializing its sets with empty HashSets Also... empty constructors are already defined if no other constructor is going to be declared, so it's redundant

EDIT:

To initialize anything more than just an empty set use the constructor

public class Location {
    public Set<ShiftTypes> shifts = new HashSet<>();
    public Location() {
        shifts.add(ShiftTypes.MORNING);
        shifts.add(ShiftTypes.AFTERNOON);
        shifts.add(ShiftTypes.NIGHT);
    }
}

This time I assumed you wanted the set in Location to be of type ShiftTypes and not ShiftType, otherwise you can't fill it with every enum type because ShiftType itself is not an enum

If ShiftType should be used (because you need the integer) then that's a whole different story you'll have to add a field in ShiftType

public class ShiftType {
    public enum ShiftTypes {
        MORNING, AFTERNOON, NIGHT
    }
    public ShiftTypes shiftTypeEnum;
    public Integer count;
    
    public ShiftType(ShiftTypes shiftTypeEnum, Integer count) {
       this.shiftTypeEnum = shiftTypeEnum;
       this.count = count;
    }
}

And the above method becomes

public class Location {
    public Set<ShiftType> shifts = new HashSet<>();
    public Location() {
        shifts.add(new ShiftType(ShiftTypes.MORNING, 0));
        shifts.add(new ShiftType(ShiftTypes.AFTERNOON, 0));
        shifts.add(new ShiftType(ShiftTypes.NIGHT, 0));
    }
}

As you've described it (with each box containing a max of 1 box) what you have is effectively a linked list. You don't need recursion for that, just walk the list keeping the current box in a variable.

But possibly what you're trying to solve for (where a box can contain multiple boxes) is a tree, and what you need is a search function for that tree. Without knowing anything of the expected node distribution in your tree, I would highly recommend doing a DFS (https://en.wikipedia.org/wiki/Depth-first_search), as this is easy to implement and is performant on a broad array of tree types.