1

In school they taught us to use getters and setters in Java. Recently I've been reading such things are bad and not OOP. Ok, so I can make some code which only sets data by using the constructor and returns the required data.

How do you not use getters with threads? When you execute a thread it's type is always void and there are on global variables in java . . .. So how do you go about getting data back from a thread without a getter method?

  • 4
    Where have you been reading that getters and setters are bad OOP? They're a staple of much of object-oriented design. – templatetypedef Feb 25 '11 at 18:33
  • Where have you been reading this? – Argote Feb 25 '11 at 18:33
  • LOL at 3 persons asking the same thing seconds apart. – Argote Feb 25 '11 at 18:34
  • 1
    " When you execute a thread it's [sic] type is always void and there are on global variables in java ." Can you rephrase that? What it that supposed to mean? – EboMike Feb 25 '11 at 18:34
  • possible duplicate of [Java: Are Getters and Setters evil?](http://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil) – Péter Török Feb 25 '11 at 18:35
  • see also [What is the point of setters and getters in java?](http://stackoverflow.com/questions/1461598/what-is-the-point-of-setters-and-getters-in-java) – Péter Török Feb 25 '11 at 18:36
  • @eboMike ex Thread t = new Thread(Whatever extends thread or runnable here); t.start; the interface is "void run()" and if you change this it gives a compiler error. –  Feb 25 '11 at 18:37
  • @DasWood: That still doesn't explain what you're trying to do. Do you want a return value? How can you have a return value if the thread is asynchronous? Are you talking about the thread passing its results back to the calling thread when it's done computing? – EboMike Feb 25 '11 at 18:38
  • @EboMike threading without getters. –  Feb 25 '11 at 18:43

3 Answers3

2

Recently I've been reading such things are bad and not OOP.

Quite the opposite, getters and setters are one of the cornerstones of OOP (where such side effects are desired).

You can however still pass constructor arguments before starting a thread, e.g., 

new Thread(new MyRunnableObject(args)).start();

If you desire it to return a result without getters, you'd best implement a Callback which the thread executes e.g, on completion.

Johan Sjöberg
  • 47,929
  • 21
  • 130
  • 148
  • 2
    Except that they breach encapsulation. Member functions should do what is appropriate for the class interface, not the class implementation. (In some cases, getters and setters are appropriate, but putting them in automatically is bad OOP.) – David Thornley Feb 25 '11 at 18:36
  • Callbacks seem like something they should have covered before. Thanks. –  Feb 25 '11 at 18:39
1

Getters or setters by themselves are not bad OO design.

What is bad is coding practice which includes a getter AND a setter for EVERY single member automatically, whether that getter/setter is needed or not (coupled with making members public which should not be public) - because this basically exposes class's implementation to outside world violating the information hiding/abstraction. Sometimes this is done automatically by IDE, which means such practice is significantly more widespread than it's hoped for.

DVK
  • 126,886
  • 32
  • 213
  • 327
  • What IDEs do this automagically? I've used Netbeans and IDEA community edition and it doesn't do these. –  Feb 25 '11 at 18:40
  • @DasWood - to be honest, I don't know - I have heard ex-co-workers discuss this capability on their IDE but they didn't mention which one it was (I have a feeling it was MS one). or could have been some fancy Eclipse plugin. – DVK Feb 25 '11 at 18:45
0

Recently I've been reading such things are bad and not OOP Who tells such crap?

Getters and Setters really are a best practice. They provide a layer for property-access so you have a single point of change when the internal workings of an accessor in a class need to be modified. You can override them in child-classes if you need to encapsulate different access strategies.

Concerning the threading:

You should use something like a threadsafe collection, I guess there are classes out there for the communication between threads. Use a threadsafe queue, which one thread writes to and the other reads from. I bet there are some good libraries for that out there. You don't really need globals. Just pass the same reference to both the classes that need to communicate across threads. You can also communicate via pipes or TCP, but that is more for inter-process communication.

Falcon
  • 3,150
  • 2
  • 24
  • 35