Campbell Ritchie wrote:Which book are you using?
Campbell Ritchie wrote:It is best to reduce mutability as much as possible.
Campbell Ritchie wrote: Also, setXXX() and getXXX() methods may break encapsulation and therefore violate some of the principles of object‑orientation. (Old thread about setXXX() methods.)[/list]
Campbell Ritchie wrote:2: If you allow the field to retain its default value, you will have your object in an inconsistent state; there is no such thing a a circle with radius 0. You might have radius 0.000...0001 but not 0. Remember there is no way to “force” your users to call any setXXX() methods.
Campbell Ritchie wrote:Don't call the method Calculate() with a capital C. Say calculateArea() or similar instead.
Campbell Ritchie wrote:
I can see two design errors in your Circle class. Please tell me what they are.
Paul Clapham wrote:There's a concept called "N-and-a-half loop" which means that a loop will be executed N and a half times. This situation occurs when the loop looks like this:
It happens fairly often, and that's what Campbell has posted there. Only in the posted code, the "initialize" part is score = myScanner.nextInt() and the break-out test is score < 0. So the "initialize" and "break out" parts can be combined and put into the loop header.
But sometimes the "initialize" part is too complicated to do that and then the loop looks like this:
You don't see this very often, though, because there's somewhat of a prejudice against breaking out of the middle of a code block which dates back a couple of decades or so, back to when "structured programming" was the new big thing. So if the "initialize" part is too complex to roll into the loop header, people will make it into a method and then put that into the loop header.
Paul Clapham wrote:I put your code fragments into the "code" tags. Please do that in future so that it's easier to discuss code fragments. (Select the code fragment in your post and click on the "Code" button at the top of the box.)
Anyway: Look at line 3 in your second code fragment. Notice that you don't have the same thing in the first code fragment, so the two aren't equivalent.
Tim Moores wrote:It will not be the same Activity object, because Android does not know beforehand which activity will be called as the result of a startActivity call (that can change dynamically at runtime). This is easy to test by comparing the references of the different activity objects.
There are other circumstances under which an existing Activity object might get reused; the Activity Lifecycle documentation talks about that.
Norm Radder wrote:
will it be same Activity B object that got called previously or a new object
Why do you need to know that? I imagine the old object is collected and a new one created as needed.