getters & setters are bad, design patterns etc.

[Cubbi]

Thinking about basic Point, Rectangle, or Circle classes - how are these going to be useful if one doesn't have access to the value of their data members?

Which is why Point, Rectangle, and Circle classes are typically not encapsulated..

Let's look at real life examples:

boost.geometry (which supports n-dimensional points in cartesian, spherical, etc coordinate sets), doesn't expose the data members of the model::point class, but it has non-member and public member getters/setters:
http://www.boost.org/doc/libs/release/libs/geometry/doc/html/geometry/reference/access/get/get_2_with_index.html
http://www.boost.org/doc/libs/release/libs/geometry/doc/html/geometry/reference/models/model_point.html
(the actual data members are a private array of CoordinateType)

boost.polygon (which only has 2D and 3D points), likewise has accessors for its point_data and point_3d_data classes: get() and set(), which take into account orientation, and, for 2D points only, x() and y() which don't
http://www.boost.org/doc/libs/release/libs/polygon/doc/gtl_point_concept.htm
(the actual data members are a private array of coordinate_type)

what do the getters do?
boost.geometry:

    template <std::size_t K>
    inline CoordinateType const& get() const
    {
        BOOST_STATIC_ASSERT(K < DimensionCount);
        return m_values[K];
    }

boost.polygon:

    inline coordinate_type get(orientation_2d orient) const {
      return coords_[orient.to_int()]; }
    inline coordinate_type get(orientation_3d orient) const {
      return coords_[orient.to_int()]; }

Even simple VSTs are more useful with at least some level of encapsulation.

[TheIdeasMan]

@ne555

I mean how to compute the angle between them

This is the proper definition of a dot product :

u dot v = u₁*v₁ + u₂*v₂ + u₃*v₃ = |u| |v| cos \theta

I am using this notation rather than u = (u_x, u_y, u_z)

Calculating the dot product by multiplying it's components is much easier than using the magnitudes.

@everyone

So it's pretty obvious that they can be badly abused. Cubbi's example is particularly bad because it's straight assignment, and completely negates the ideas of deposit or withdrawal.

But it doesn't mean that they can't be written properly with checks & validation.

Maybe this topic fits into the same category as when a beginner routinely does while(true){} , because they can't bothered thinking of an end condition, but there are situations where an infinite loop done properly is a good thing.

Can anyone show how they think a Circle class should look? So that a DrawTangentLine calculation can be done with 2 circles? Without get functions? There is no need to show any calculations - I would just like to see how the data is accessed.

Does anyone have any thoughts on the GUI problem I mentioned above?

Any way it's late again - so I will see what anyone has to say tomorrow :)

Edit: Really slow typing again. I didn't see the last 2 posts while I was doing mine. Cubbi - you are a champion - I will look at that info tmrw.

[moorecm]

The most common case that bugs me is the use of memset associated with C-style structs. (When I say C-style, I mean all public member data AND no member functions.)

Here's an example:

struct config {
    uint64_t a;
    uint8_t b;
    bool c;
};

//...

config c;
memset( &c, 0, sizeof(config) );
c.a = 1;

Many C folks will try to defend that against this:

struct config {
    config() : a(), b(), c() {} // zero the instance at construction
    uint64_t a;
    uint8_t b;
    bool c;
};

//...

config c;
c.a = 1;

I've found the memset approach to be more error-prone because it can be forgotten, misused, etc..

Now, that said, we can still do better with encapsulation. Does it take a little extra time? Sure. A few seconds per member if you're just going through the motion of adding getter/setter per data member but it can take longer if a minimally complete API is being designed.

Is it worth it? That is, of course, a question you all may ask yourselves and form your own conclusions. My conclusion was that it is always worth it.

[Cubbi]

That's a very 1989 kind of C coding...

[LB]

@Cubbi examples: Those classes manage themselves to some extent (e.g. the static assert and the orient.to_int) so they require some level of encapsulation. Whether accessors or mimics are used (or a combination of both) is a matter of preference. All have their advantages and drawbacks depending on a wide range of circumstances including actual use and they have to account for many use cases.

If you're not writing a library to be sued by others though, you can reduce to fit the needs of your project and its expected future generally there is little to no encapsulation for your basic My2DVectorClass, most likely POD for efficiency with some helper functions to perform dot products and such.


I think there is a large disconnect between people when it comes to the difference between classes that manage themselves and classes that allow themselves to be managed. Let's all calm down and try to figure this out.

[DeXecipher]

Java overuses/abuses getters and setters in my opinion, probrably because it doesn't support operator overloading. This is why I prefer c++, as it is less verbose.

[LB]

@DeXecipher: please support your claim with evidence.

[DeXecipher]

@LB

My claim is supported by personal experience. Compared to c++, java is more verbose, that is a fact. From the gate you have classes, while c++ has a main driver that is just a function. C++ doesn't really force you to learn anything object oriented from the beginning because it is a superset of C. In java almost everything aside from data types is a class, which introduces a whole new paradigm of typing. C++ supports operator overloading which can make coding shorter if you know the operators, while in java most things are getters and setters. In c++ you have more option syntactically, period.

[LB]

DeXecipher wrote:

Compared to c++, java is more verbose, that is a fact.

Bjarne himself advocates that C++ programmers should write more verbose code, so you must have a point.

The only mention of "getter" or "setter" in your post:

DeXecipher wrote:

while in java most things are getters and setters.

Please reread my original request:

L B wrote:

@DeXecipher: please support your claim with evidence.

[MiiNiPaa]

please support your claim with evidence.

Well only claim I see in his post is that Java does not support operator overloading an it is truth.

But on the other hand there is many C++ programmers who often overloads operators without saving their semantic: + operator changing it operands, ! operator used as state reset function, unary - as "close active connections" one.
Java forces you to name your functions and you can be sure that operator will never change their meaning. But absense of non-member functions is pushing me off it. I understand that using static classes as namespaces is Java way, but I just don't like it.

[LB]

@MiiNiPaa To me it sounds like you're suggesting that by not having operator overloading or const correctness you can prevent people from writing code that doesn't do what it says it does.

In other words, I don't see how your argument is any more valid than saying "using letters makes code work better than using symbols"

[DeXecipher]

@LB

I read it, maybe my claim is more of a conjecture, because it is backed by experience, but I would like to know how many other languages you've mastered/coded in.

[MiiNiPaa]

I speculated about what Java creators were thinking when they decided to not include operator overloading in Java.
I do not like this decision, and people will write bad code anyway, even in most foolproof language.
But I do not think that this choice was "bad" or "good". It is part of language design and there other ways which Java users are advised to take. Everything else is a matter of personal preference :)

[LB]

I don't see what programming experience has to do with the statement "Java overuses/abuses getters and setters". I'm more concerned with the fact that it is followed by "in my opinion".

[3qX21hU5]

And why are you so concerned about other peoples opinions? If his opinion is that java users getters and setters more then C++ that is fine. In my opinion the color blue is the best color do I need to back up that opinion with evidence ; p

[LB]

I'm concerned that a programmer after 3 years of experience still clings to personal opinions about other languages.

[3qX21hU5]

Programmers of 10 years of experience still cling to personal opinion about languages. Its not something you get rid of... like what style you prefer K&R or not. Whether you like camelcase or underscores. Whether you think java is better with Databases or not.

But anyways a bit off topic sorry about that

[o1vk4iN6]

DeX wrote:

C++ supports operator overloading which can make coding shorter if you know the operators, while in java most things are getters and setters. In c++ you have more option syntactically, period.

Don't really see how operator overloading is a replacement for getters/setters but ok. I guess instead of a = obj.getSomething(); you do a = obj++; // equivalent to getSomething(), bit ambiguous no? . Only use I see for operator overloading is if you are adding your own mathematical objects, such as vectors/matrices with dot products. Possible some other uses like simulating other objects in the case of smart pointers and dereferencing. Other than that there isn't a whole lot use for it without your coding being hard to read.

That is to say it isn't nice, had to do a couple matrix multiplication in Java which turned out being something like:

mm( mm( mm( mm( a, b ), c ), d ), e);

as opposed to

a * b * c * d * e

Maybe rabidcoder has a better solution ?

[DeXecipher]

your problem is you care too much about opinion.

[Lachlan Easton]

your problem is you care too much about opinion.

Is that just in your opinion?