Well it’s not exactly the “correct” way to decompose things, but not bad for a first attempt, and your approach is very typical for those who are new to OOP.
With that out of the way, one of the first principles in OOP is that everything is an object—whether it’s the application window itself or any of the “objects” within the window. So let’s take your visual mock-up of 5 comments. I’m a bit rusty on my UML, but it looks like you created 4 classes? I only see one class to take away from the mock-up: a singular comment. So there should only be one class in your UML diagram for a comment. Let’s call this the Comment class. And using object-oriented terminology, the Comment class should have a Like, which could be either yet another class (a Like class), or possibly an array. The Comment class should also have a string attribute to hold the comment text itself. And so on—so as you can see, each concrete Comment will have its own attributes and possibly methods. This is how you should think about OOP.
Anytime you see more than one potential object, generally they fall into one of two hierarchies—“has-a” or “is-a”. The “has-a” means one class will have one or more instances of another class. One such classic example is when you have a Car class that has a Tire class. No Car has only one Tire, so the Car class would have four Tires. In your visual mock-up then, you could create a CommentBox class. This would contain an array of Comments—basically, representing the list of comments on the screen.
But wait, you also have sub-comments, right? Those will all just be Comment objects themselves as well. So clearly all you have to do is add an attribute to your Comment class indicating any other Comments attached to it. This could take the form of a dynamic array, since you don’t know in advance how many Comments will be categorized as sub-comments.
If you’re following what I’m saying, this is basically how you should think about OOP. Everything is an object, and every time you see more than thing that probably should be permutations of each other, that usually means they should all derive from one class. This is how you create maintainable software as well—you don’t want to make too many classes, because having too many classes isn’t maintainable. And whenever you see a bunch of similar-looking objects on the screen, that probably means an array of objects will be in order somewhere.
I don’t have a UML diagramming tool installed on my computer right now, but this might be one approach representing your visual mock-up, written in Java:
public class CommentBox
private ArrayList<Comment> listOfComments;
public class Comment
private ArrayList<Comment> subComments;
private String commentText;
private String commentTitle;
private int likes;