Object oriented programming decomposition

Object oriented programming decomposition
0.0 0

#1

Can anyone familiar with OOP suggest the best way to decompose this block with comments?

I created the following diagram for it. But I don’t know a lot about OOP and I am not sure if it’s correct way of decomposing.

Any advice is greatly appreciated!


#2

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.

The first thing to keep in mind when it comes to OOP, especially since we’re on FCC, is that JavaScript doesn’t actually follow OOP, even in ES6/ES2015. When you’re talking about OOP, we’re really talking about object-oriented languages like C++/C#, Java, and Python.

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; 
}

#3

Thank you very much for this very thorough reply! It helps a lot. I see that I can use only two classes.


#4

Sure no problem. Keep in mind that the Java example code is just what I came up with on the spur of the moment, and would probably be re-factored somewhat for a real project. In particular, I’m not entirely sure it makes sense to use an ArrayList for subComments, and the int likes variable naturally will only indicate how many likes a Comment would have, and nothing else—if you wanted to store any other data related to Likes, it might make sense to use an ArrayList instead.

Also, the information being shown in the visual mock-up could just as easily be stored in either a relational or document database, so that could change the application entirely.


#5

OOP is more of a programming style/method, rather than a format for storing data.

For your commenting system, I think using a non-relational (i.e. noSQL) format, like MongoDB where documents/records are stored as Objects (i.e. JSON format) and you can have objects within objects, is probably more suited for this.

https://university.mongodb.com