Win a copy of Terraform in Action this week in the Cloud forum!

Jesse Silverman

Saloon Keeper
+ Follow
since Oct 25, 2020
Jesse likes ...
Eclipse IDE Postgres Database C++ Java
Been programming "since forever" but Java was always a second (or third) language. It's moving to the front seat. I'm mostly harmless.
New York
Cows and Likes
Cows
Total received
61
In last 30 days
20
Total given
1
Likes
Total received
240
Received in last 30 days
28
Total given
1013
Given in last 30 days
239
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt Green check
expand Greenhorn Scavenger Hunt Green check

Recent posts by Jesse Silverman

Interesting to note that Holub referenced the classic Dunning-Kruger study way back in an article from January 2004, linked above.
Just noticed that for the first time on a re-read.

Anyway, this seemed quite relevant from some stuff I am reading right now:
http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/

Seems like a different topic, right?

Well, point 9 speaks to the advisability of getters and setters in Java:

Misko Hevery wrote:Mixing Service Objects with Value Objects: There should be two kinds of objects in your application.
(1) Value-objects, these tend to have lots of getters / setters and are very easy to construct are never mocked, and probably don’t need an interface. (Example: LinkedList, Map, User, EmailAddress, Email, CreditCard, etc…).
(2) Service-objects which do the interesting work, their constructors ask for lots of other objects for colaboration, are good candidates for mocking, tend to have an interface and tend to have multiple implementations (Example: MailServer, CreditCardProcessor, UserAthenticator, AddressValidator).
A value-object should never take a service object in its constructor (since than it is not easy to construct). Value-objects are the leafs of your application graph and tend to be created freely with the “new” operator directly in line with your business logic (exception to point 1 since they are leafs).
Service-objects are harder to construct and as a result are never constructed with a new operator in-line, (instead use factory / DI-framework) for the object graph construction. Service-objects don’t take value-objects in their constructors since DI-frameworks tend to be unaware about the how to create a value-object.
From a testing point of view we like value-objects since we can just create them on the fly and assert on their state. Service-objects are harder to test since their state is not clear and they are all about collaboration and as a result we are forced to use mocking, something which we want to minimize. Mixing the two creates a hybrid which has no advantages of value-objects and all the baggage of service-object.



This is from back in 2008, when Java was Java 6 (not that the article is only applicable to Java).

It seems like the concept of "value objects" has been somewhat elevated in Java since that time.
39 minutes ago
Yes, many similar questions implement an interface, so the "default" in the interface is to "public", and an override must be public as well -- but that is not the case in this question.
I noticed a curious thing.

Reading and watching other really good material on how to make your designs easily testable (and other topics that overlapped with this goal) kept coming back to  Miško Hevery.

They would say "There's great reasons for doing it this way, this isn't the place to talk about why if you don't know, go watch or read  Miško Hevery."

I feel like they were right.

Critics mostly say his stuff is obvious, but his target audience is beginners and intermediate designers, as well as those who have been doing things wrong from a testability (and probably reusability and maintenance perspective to for that matter) for so long that they have stopped thinking about it.

I gave someone a link somewhere to one piece, and one can link-surf from there, but as I was following them and closing them I decided to place them all here, because it is, in my opinion, such a good place to pick up a lot of good insight and good habits.

So here is a chronological dump of links to his site, there's many more pages of good stuff there, but these are the ones I left open:

http://misko.hevery.com/2008/07/24/how-to-write-3v1l-untestable-code/
http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/
http://misko.hevery.com/2008/08/21/where-have-all-the-singletons-gone/
http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
http://misko.hevery.com/2008/08/29/my-main-method-is-better-than-yours/
http://misko.hevery.com/2008/09/10/where-have-all-the-new-operators-gone/
http://misko.hevery.com/2008/09/24/application-wiring-on-auto-pilot/
http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/
http://misko.hevery.com/2008/10/27/pass-around-ginormous-context-objects/
http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
http://misko.hevery.com/2008/11/17/unified-theory-of-bugs/
http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/
http://misko.hevery.com/2009/07/31/how-to-think-about-oo/
http://misko.hevery.com/2009/01/14/when-to-use-dependency-injection/

Maybe these are all summed up here?  I am not sure yet:
http://misko.hevery.com/code-reviewers-guide/

I have spent a LOT of time working with code that violated most of these things.  A LOT.
The results could be described in the words of the late Warren Zevon "Ain't That Pretty at All"!
17 hours ago
This blog post from an excellent series aimed at Testing Best Practices for Beginners (and Intermediate people) refers to the definition of Test Driven Design:
https://defragdev.com/blog/2012/10/27/the-fundamentals-of-automated-testing-spring-the-trap.html

They make an interesting point:
One error that is easy to make is writing tests that can never fail, and I have seen plenty of those!

When you write the test first and see it fail, you know for sure it can fail because you've seen it do so.

I never quite thought of this exactly like that before, it is a ridiculously obvious but easy-to-overlook point.

Note that a test that can never fail is still a test case, just a really bad and useless one.
Near the start of that series he talks about "Totally Useless Tests" in general, and the fact that they are actually extremely common.

TDD is one way of many discussed to not accidentally write useless tests.
19 hours ago
I am reading a lot about Testing Best Practices right now.

There are many books and several great ones covering these areas.

However, I also am liking this blog post series, and, hey, it is free:
https://defragdev.com/blog/2012/10/24/the-fundamentals-of-automated-testing-series.html

You might gain a lot from these, as they go back to the fundamentals of what writing good tests looks like.

It is fairly basic, and doesn't get too much into the details of any specific testing framework, but general principles of "What should the tests themselves look like?"

I think it is very clearly written.

If you take a look, let me know what you think of them.
22 hours ago
Thank you.

Since this is Jeanne's thread, and most of my attention to "what happens when we use Raw Types in different places?" has been OCJP-related, I trust she will be the first to let us know the good news if Oracle ever decides to stop putting tricky "Raw Types"-related questions on the exams.

For now, I will try to use them even less frequently than I had been, which is to say, already very rarely.
1 day ago
I believe this is one of many areas where there are surprising behaviors explained by some of the densest and most impenetrable parts of the JLS that are avoided by avoiding all avoidable uses of Raw Types?

I am one of the Java people who would just try to avoid all uses of Raw Types wherever possible, except for purposes of OCJP exam questions.

If the OCJP would give up on tricky questions about "Behaviors in absence of type parameters where they are allowed but not required for legacy reasons" I would be left with only one question:

"Where are we ever forced to use Raw Types?"
rather than "What do the hardest-to-read sections of the JLS say about type inference in the presence of Raw Types?"

So:
"Where are we ever forced to use Raw Types?"

I'd rather never see them appear in any code I need to work with except in those occasions, I find generics and type inference tricky enough without them.
1 day ago
Can you name, name, name
Name 'em today?

I got distracted on other questions and listening to music, but not before I confirmed that THIS worked:

       opt.<RuntimeException>orElseThrow(RuntimeException::new);

I knew that would work, and it doesn't answer the question completely yet.

It's a true fact tho.
1 day ago
Your break on line 46 means that the loop will only ever run thru a maximum of one time.

That is, it is the same as if you had said:
for (j = 0; j <= 0; j++) {

on line 39.

What did you mean for the logic for the loop to be?
1 day ago
Not the most important topic, but many questions relate to the singleton pattern. It's a deceptively simple pattern with subtle problems (to the point that some call it an AntiPattern). Forum regulars often suggest that you Just Create One and use Dependency Injection to get it into the system.




A singleton is a class of which there cannot be multiple instances. It is one of the GangOfFour DesignPatterns.

In contrast to a class with all static methods (often called helper class), the singleton pattern encapsulates the knowledge of how many instances and of which actual class are used, thereby providing the option of making use of polymorphism. That is, you can change the implementation used for the Singleton based on some external stimulus (property file or something) without the clients even noticing.

Related Forum Threads:

  • Google:site:coderanch.com+singleton


  • Other Resources:

  • What is a Singleton (Frank Carver)
  • Wiki:SingletonPattern
  • Singleton vs. Just Create One (Robert C. Martin)
  • Singleton and Monostate (pdf) (Robert C. Martin)WaybackMachine
  • Singleton and Monostate (pdf) (Robert C. Martin)(University of Turku, Finland)
  • Use your singletons wisely (J.B. Rainsberger)(Original: WaybackMachine)
  • Use your singletons wisely (J.B. Rainsberger)(Updates 10 and 17 years later by original author!)
  • Singleton Pattern Deep Dive: Why is it bad? (Sihui Huang)(Blog Post from 2020)
  • When is a Singleton not a Singleton? (Joshua Fox)
  • Updated wisdom on how some of the issues mentioned in the link above play out in Modern Java (Alex Miller)
  • Patterns I Hate #1: Singleton (Alex Miller)
  • From the author of Testability Explorer--Several Linked Articles About the Disadvantages of Singletons (Misko Hevery)
  • Singleton considered stupid (Steve Yegge)




  • If you are thinking of using the singleton pattern, resist with all your might. It is one of the easiest DesignPatterns to understand, probably the most popular, and definitely the most abused. Use a singleton only if there is a fundamental reason inherent to your problem or your design why there can only be one instance of your class. "I need only one instance in this application" is not a fundamental reason: using a singleton will unnecessary constrain the evolution and reuse of your code, and also makes it harder to understand because you're giving your reader the wrong signals. "I need easy access to shared data using a static method" is also not a valid reason: an InversionOfControl framework such as the SpringFramework or PicoContainer is a much better way to go about that. -- PeterDenHaan
    1 day ago
    Hi Stefan:

    I added code tags in case we needed to refer to specific lines.

    As written, their code generates three compile errors on a total of two lines.

    As much as I hate this kind of question, because of downstream effects where a single compile error might cause one or two or three more, or hide one or more, so that "minimum number of lines that need to be changed to be correct" might != "number of lines mentioned by the compiler in error output"...

    In this case, there are two lines that I consider wrong--fortunately the compiler agrees!

    When we change the code to this (note, only two lines contain changes) we get a happy, successful compile:

    jshell> public class HowLong {
      ...>         public void main(String h) {
      ...>                 LocalDate newYears = LocalDate.of(2017, 1, 1);
      ...>                 Period period = Period.ofYears(1).ofDays(1);
      ...>                 DateTimeFormatter format = DateTimeFormatter.ofPattern("MM-dd-yyyy");
      ...>                 System.out.print(format.format(newYears.minus(period)));
      ...>         }
      ...> }

    Cleaned up a bit because I was in JShell...:


    Additionally, this code demonstrates how Dang Tricky the exams like to be.

    You may notice that for two different reasons, it is not declared static and the parameter list doesn't match, this main() method will not be callable from the command line, but only from a static method added to HowLong class or from outside by someone who already has a HowLong instance.

    However, these issues are not compile errors.  They would come into play if they asked "What will be the output if this class is compiled and run?" but here they don't ask that.  Something like 20% of the test is reading comprehension on subtle points.
    Even from a selfish standpoint, and I have known a couple, well, at least one person who many considered very selfish who appreciated this:

    There is truly no better way to know that you have really learned something well and have no mastered it than to find and explain away confusion that others have.

    It is also a very good way to get better at clear technical writing in English, whether English is one's first, second or third language.

    So while I think it is great to participate in a spirit of Altruism, I think that even in a narrow-minded selfish way I have gotten a lot of benefit from my participation here.

    There are other sites that are more narrowly limited to Question-and-Answer from strangers that feel totally different.

    Tho the percentage of "regulars" is small compared to total visitors, CodeRanch does indeed still feel like a community to me.

    That is rather unique at this point, some find it "quaint" but I really like it, personally.

    There's enough people here that we often have very different viewpoints (ask two programmers how to best do something and you will get three answers!) and getting ever-better at consuming, understanding, and sometimes respectfully disagreeing with the opinions of others is also very important and not something everyone really learns at school, as well.

    I think you may find that there are attractive properties to CodeRanch that should be much less unique to the site than they have become in recent times.

    Welcome to the Ranch!
    1 day ago
    Complete agreement with Tim with the lone exception that some people seem to strictly define Test Driven Design:
    "The Test Cases Get Written First, then we write code until the Test Cases Pass, then we are Done".

    I would personally be fine with calling "We write them about the same time, and don't say we are done until we have all our necessary test cases and they are passing" TDD, but some are sticklers.

    Either way is far smarter, safer, better than "We wrote all our code, have no idea what works, and we planned to have a week to write and run tests at the end, but we ran out of time so we only have one afternoon for that before code freeze"!

    I might also say that among those who value testing in Java, JUnit is more like super, totally uber-popular, people will vary more on what extras or add-ons they throw in on top of basic JUnit to make their own specific tests more useful, readable and maintainable.

    Even the worst of the three little pigs described above would be said to have test cases, however.
    They won't have enough, they won't have them soon enough to detect problems that will now have to be fixed by undoing work, etc. -- but they will still have them.

    Any code written purely to verify that some code is working correctly is still properly called a test case, regardless of when it is written (at the same time or before the code it calls is great) or whether someone uses the very standard JUnit, some other testing framework, or just writes their own.  Within JUnit there is additional specific terminology, but test cases predated JUnit, and in fact, Java.
    1 day ago
    One pattern you will see, over many years, some people coming around a lot when they need help because they are doing something new to them, then go away for quite some time, then come back again when they need help again.

    A smaller percentage make a large effort to give back to the community by consistently helping the other people that wander in and out.

    Much a microcosm of the Real World.
    2 days ago

    Campbell Ritchie wrote:

    Junilu Lacar wrote:. . .

    That reminds me of what we used to write when I did O level maths: 10 ≤ x ≤ 20. I know no programming language where that sort of thing will compile;



    Hi Campbell:
    While Python is most commonly interpreted, rather than compiled, it has EXACTLY what you wished you could say succinctly.
    >>> a = 5
    >>> 2 < a < 6
    True
    >>> 2 < a < 5
    False
    >>> 4 < a < 6
    True
    >>> 4 < a < 5
    False


    When I read your comment, I had to do a double-take to think if I was remembering this wrongly in Python, which is getting pretty common these days!
    2 days ago