Reputation
Next privilege 1,000 Rep.
See votes, expandable usercard
Badges
7 14
Newest
 Nice Answer
Impact
~326k people reached

May
23
comment How do you avoid getters and setters?
@RolandTepp: I don't really want to derail the comments on this question. But my point was that omitting the "get" prefix is also a valid idiom in Java. Since there are multiple possible idioms which are both in wide use (see my previous comment, which you say you do not disagree with), I don't see how adopting one idiom over another -- in contexts where you have the choice -- is "pure hubris" or results in reduced code readability. You are free to disagree, and I don't begrudge you your opinion. Perhaps you should open a separate question about the naming convention?
May
21
comment How do you avoid getters and setters?
@RolandTepp: You're saying that naming a method size() or ordinal() rather than getSize() or getOrdinal() is not idiomatic? Better change all collection types in the standard library and the definition of enums in the language spec then, because those don't use the "get" prefix. There are plenty of other examples I can find. Basically: I reject the premise that the "get" prefix is an idiom of the language, only of some libraries of the language.
May
20
comment How do you avoid getters and setters?
@RobertHarvey: Are we talking exclusively about enterprise Java here, though? Like I said in my comment above, I personally think you should avoid specs like JavaBeans if you don't need them -- but if you do need them, then yeah, ignore my advice. :-)
May
20
comment How do you avoid getters and setters?
@IntelliData: It depends on what you're modeling Customer to mean. If you model Customer to mean "the knowledge I have about a customer at a point in time", then it can freely be immutable; when you have more knowledge you just create a different instance. In fact that can be a much easier way to model data if you have both local (in-memory) and remote (database) structures: the Customer object in memory will by necessity not always be identical to the Customer record in the database, so being able to represent them differently (and being to compare between them) can be very useful.
May
20
comment How do you avoid getters and setters?
@RobertHarvey: They are indeed, and that's a good way to articulate why I don't like the name(new_name) form. I don't believe that naming methods after verbs is a hard rule though, so I have no objection to naming a (non-state-changing, obvious-from-context) method after a noun. I realize that not everyone concurs with this opinion, though.
May
19
comment How do you avoid getters and setters?
@IntelliData: As a method with no arguments, it cannot be a setter. The pattern of using methods named after the properties exists throughout the Java standard library (Collection.size() for example) and is quite common in other languages as well (I see it a lot in C++ code, for example). I've seen people make name() the getter and name(new_name) the setter, although I'd shy away from that in favor of having an explicit setName(), or better yet omitting setters entirely. IMO, value objects should always be immutable unless there's a strong need for them to be otherwise.
May
18
comment How do you avoid getters and setters?
...and, from the opposite perspective from MichaelT: if you're not using the JavaBeans spec (and I personally think you should avoid it unless you're using your object in a context where it's necessary), then there's no need for the "get" wart on getters, especially for properties that don't have any corresponding setter. I think a method called name() on Customer is as clear, or clearer, than a method called getName().
Apr
6
awarded  Nice Answer
Mar
27
comment What causes floating point rounding errors?
@robert: The point I was trying to make was that the OP's premise for this question is not necessarily valid. Floating point math doesn't introduce more error than fixed point -- actually it can introduce less error (especially relative to bits used). There are good reasons to use fixed point or decimal floating point, but "not understanding how binary floating point behaves" isn't a good reason IMO. And BTW, no, .NET's decimal isn't like BCD at all -- it has a mantissa and exponent, just in base 10. BCD is a whole other kettle of fish. :-)
Mar
27
comment What causes floating point rounding errors?
You can do floating point numbers in base 10 -- that's how .NET's decimal type works. Fixed point, on the other hand, is different. As long as your range is limited, fixed point is a fine answer. But the restrictive range makes fixed point unsuitable for many mathematical applications, and implementations of fixed point numbers are often not well optimized in hardware as a result.
Mar
27
comment What causes floating point rounding errors?
@robert: That's not exactly what I was referring to. The "error" most people encounter with floating point isn't anything to do with floating point per se, it's the base. IEEE-754 floats and doubles use an exponent in base 2, which means that fractional numbers round off to negative powers of two (1/2, 1/16, 1/1024, etc.) rather than negative powers of 10 (1/10, 1/1000, etc.) This leads to unintuitive results like 0.1 rounding to 0.1000001 and similar issues.
Mar
18
comment When is it a good idea to force garbage collection?
@JimmyHoffa: you say "everything that Main() references ... will be rooted until your Main() returns at the end of your process." That's not necessarily true. An object can become eligible for collection during execution of a method on that very object.
Mar
18
comment When is it a good idea to force garbage collection?
If you haven't yet read Raymond Chen's post Everybody thinks about garbage collection the wrong way (and follow-up articles like When does an object become available for garbage collection?) then you really should.
Feb
10
comment Are there any easy-to-follow/reliable methods for simplifying code?
@AgiHammerthief: Some people think that design patterns are things you should do, as if they were a checklist of some kind. Not so. Design patterns are a language you use to communicate to other programmers the ideas you're using to solve your problems. That is, when someone tells me they're using a Factory, or a Builder, or whatever, that's just a way to communicate. Patterns don't themselves make code good or bad -- the code can be that all by itself.
Oct
21
answered Why are floating point numbers used often in Science/Engineering?
Oct
15
awarded  Yearling
Jul
2
comment Why is the finalize method included in Java?
@rwong: Indeed. There are very few environments where (a) native leaks are a serious problem, (b) there is insufficient redundancy to tolerate JVM restarts, (c) there is no practical way to structure or audit the codebase to ensure that close() methods or similar are actually called, and (d) a sometime-later best-effort cleanup process is actually sufficient. In a case where all of those are true, then finalizers are perhaps a good solution. However, I think the advice to Read Effective Java first is sound: unless you fully understand finalizers, you're probably not competent to use them.
Jun
26
comment Why is the finalize method included in Java?
Even in the native peer case, I think PhantomReference is a better solution. Finalizers are a wart left over from the early days of Java, and like Object.clone() and raw types, are a part of the language best forgotten.
Jun
26
comment Why is the finalize method included in Java?
I guess I didn't spell it out well in my answer, but (IMO) the answer to "why does it exist?" is "it shouldn't". For those rare cases where you really need a finalization operation, you probably want to build it yourself with PhantomReference and ReferenceQueue instead.
Jun
26
answered Why is the finalize method included in Java?