Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Isn't there a point where encapsulation gets ridiculous?

For my software development programming class we were supposed to make a "Feed Manager" type program for RSS feeds. Here is how I handled the implementation of FeedItems.

Nice and simple:

struct FeedItem {
    string title;
    string description;
    string url;
}

I got marked down for that, the "correct" example answer is as follows:

class FeedItem
{
public:
    FeedItem(string title, string description, string url);

    inline string getTitle() const { return this->title; }
    inline string getDescription() const { return this->description; }
    inline string getURL() const { return this->url; }

    inline void setTitle(string title) { this->title = title; }
    inline void setDescription(string description){ this->description = description; }
    inline void setURL(string url) { this->url = url; }

private:
    string title;
    string description;
    string url;
};

Now to me, this seems stupid. I honestly can't believe I got marked down, when this does the exact same thing that mine does with a lot more overhead.


It reminds me of how in C# people always do this:

public class Example
{
    private int _myint;

    public int MyInt
    {
        get
        {
            return this._myint;
        }
        set
        {
            this._myint = value;
        }
    }
}

I mean I GET why they do it, maybe later on they want to validate the data in the setter or increment it in the getter. But why don't you people just do THIS UNTIL that situation arises?

public class Example
{
    public int MyInt;
}

Sorry this is kind of a rant and not really a question, but the redundancy is maddening to me. Why are getters and setters so loved, when they are unneeded?

like image 756
y2k Avatar asked Nov 11 '09 02:11

y2k


People also ask

What is the main reason for encapsulation?

Encapsulation is used to hide the values or state of a structured data object inside a class, preventing direct access to them by clients in a way that could expose hidden implementation details or violate state invariance maintained by the methods. This mechanism is not unique to OOP.

Do getters and setters break encapsulation?

Having getters and setters does not in itself break encapsulation. What does break encapsulation is having a getter and a setter for every data member (every field, in java lingo). That is one step away from making all data members public.

What are the three types of encapsulation?

There are three different methods of chemical encapsulation, namely, coacervation, molecular inclusion [7], and cocrystallization [8].

Why is OOP so popular?

OOP become a popular since it provide a better programming style, you don't need to write code which you really need to run anytime you need (such as in structured programming and assembler), you just make a class of object and you may call/instantiate the class and use it from any part of your application, it is ...


1 Answers

It's an issue of "best practice" and style.

  • You don't ever want to expose your data members directly. You always want to be able to control how they are accessed. I agree, in this instance, it seems a bit ridiculous, but it is intended to teach you that style so you get used to it.
  • It helps to define a consistent interface for classes. You always know how to get to something --> calling its get method.

Then there's also the reusability issue. Say, down the road, you need to change what happens when somebody accesses a data member. You can do that without forcing clients to recompile code. You can simply change the method in the class and guarantee that the new logic is utilized.

like image 137
Chris Thompson Avatar answered Sep 28 '22 17:09

Chris Thompson