When I saw your code, I thought that was a class declaration, not a
constructor (and I suspect Roedy made the same mistake). He's right that you
can't have arbitrary code directly inside a class, and you're right that you
can have arbitrary code inside a constructor. To avoid confusion, you might
want to format your code into an SSCCE so everyone knows exactly what's
going on. http://mindprod.com/jgloss/sscce.html

   As for Mark Allen Weiss and good coding style... well, let's just say I
personally wouldn't put "while(valid = false) { loginScreen.setVisible(
true ) ; /* ... */ }" inside of a constructor.

   - Oliver

As Oliver points out in his reply, I think Roedy thought that you were
posting the code for a class, and not for a constructor. I believe he
thought that because of a combination of a) you didn't post the outer
class definition, only a constructor,  and b) the code in that
constructor looked very non-constructor indeed!
The code is 'valid' in that it will run, yes. However, the code is not
well written, in that it is doing waaay too much inside a constructor.

Mark Allen Weiss, your code (as posted here) is not well written. There
you go. Please show him this if you feel like it, and invite him to join
the discussion!
Just out of interest, do you always assume that Professors know the
best, at all times? It's not always the case. No en-masse slight
intended to those in academia, but: I've seen staff-written code given
to students on computer science degrees (at the most venerable
institutions) that was questionable in its practices. Lecturers and
professors are not perfect, please disabuse yourself of the notion that
they necessarily create good code! (Contrariwise, I'm sure some of them
are very good...)

As to why that code is not well written - here is why:
Classes in OO represent nouns (or 'things'), and are named as such. You
can still have a class as a noun while also suggesting what it does
(i.e. provide a verb). An example is the code you posted, which was for
a class called Director: a director being a thing (noun) that directs.
As another example, a class that handles FTP connections might be called
FTPAgent, or FTPConnectionManager, or similar. Examples of poorly named
classes might be Direct or Connect. These are verbs.

(Bear with me a little longer...)

Now, because classes should be nouns (things), and constructors are for
constructing these things, it doesn't make a lot of sense for a
constructor to actually *do* many things. A constructor should construct
something - an object instance - that's the semantics of construct. The
*actions* (think verbs) an object performs should generally be presented
as methods (and that includes populating a non-trivial GUI component or
showing a GUI component).

You may think this is all wishy washy hair splitting, but there are
good reasons to follow these guidelines. People sometimes get burnt
trying to do too much in constructors: to see why, try the following:

Q: What does the code below output to the screen? (You're not allowed to
run it. Just answer by reading the code.)

(I'd like you to ask your professor too. And if he knows the correct
answer, why does he think it's a great idea to encourage people to shove
reams of code into a constructor?)

class A {

       public A() {
               setUpSomeThings();
       }

       protected void setUpSomeThings() {
               // some setup code in here
       }

}

public class B extends A {
       private int memberVariable = 0;

       public B() {
               super();

               System.out.println("memberVariable = "
                       + memberVariable);
       }

       protected void setUpSomeThings() {
               memberVariable = 7;
       }

       public static void main(String[] args) {
               B bInstance = new B();
       }

}

Bonus question: What is the output if we change the line:

       private int memberVariable = 0;

to:

       private int memberVariable;

?

... with really bad habits vis a vis Java constructors, apparently. I am
not impressed with this style.

I've just looked up your Professors site. Here's a sample of his code:

   private static int max3( int a, int b, int c )
   {
       return a > b ? a > c ? a : c : b > c ? b : c;
   }

Can you see anything wrong with this style? Put simply, it's a confusing
mess. Maybe putting this into one line, without even any brackets, gave
him warm fuzzies and made him feel clever. Great for him, crap for
anyone else who comes along (including him at a later date, possibly).
Just the act of adding some brackets makes that code vastly more readable:

       return a > b ? (a > c ? a : c) : ( b > c ? b : c);

And arguably you could even have:
   
    if (a > b) {
        return a > c ? a : c;
    }
    return b > c ? b : c;

Some people would cry "but it's obvious what the method does from the
name, it gives you the maximum of three params!" - no, it's obvious from
the name what method *should* (and may, or may not) do.

(Observation: your Prof seems to be used to writing and handing out code
for others, but not so used to being on the receiving end of code
written by others.)

I'm very sure that he didn't mean it as poking fun. He just got the
wrong end of the stick about the meaning of the code you posted (i.e.
thinking that it was a class, not a constructor).

As a final note, there are some guidelines for a misery-free existence
regarding constructors:

1. Do as little as possible in constructors. If you need lots of logic
concerning object creation, favour factory methods or similar.

2. Ideally, don't call non-final and non-private methods from
constructors of non-final classes.

3. If you break rule 2, document this, and don't access any object state
from these methods.

These rules may seem a little esoteric but they avoid the sorts of
shenanigans illustrated by my code question above.

"DyslexicAnaboko" wrote...

Of course, but only if those other classes belongs to another *named*
package.

I believe you've already done that.

Not that you showed those parts of your own code, but I guess you've used
the "import" statements?

That's how it's done.

// Bjorn A

DyslexicAnaboko schrieb:

Hm. I'm not Oliver. Do you accept an answer from me too?

Yes.

That's probably because the question is so very basic. Have you ever
learned the language basics? This tutorial from sun should help you out:

http://java.sun.com/docs/books/tutorial/java/index.html

Timo

   As other have mentioned the way to do it is with an "import" statement.
At the top of your class file, you write "import" followed by the fully
qualified name of the class. For example, if I wanted to make the class
"ArrayList" in the package "java.util" available to my file, even though my
file isn't part of the "java.util" package, I'd write "import
java.util.ArrayList;"

   Note that this only works if the class I'm trying to import is part of a
package. If you have "packageless" classes, then you can't import them.

   - Oliver

Sure it is possible. Actually it is so common, that every real-life program
does it all the time.

Here is an example:

// file pkg1/A.java
package pkg1;
import pkg2.B;

public class A {
 public doSomething() {
   B b = ...;  // get or create an instance of B
   b.doSomethingElse();
 }
}

// file pkg2/B.java
package pkg2;

public class B {
 public doSomethingElse() {
   //...
 }
 // ...other methods and constructors
}

All this is described near the beginning of every good java text-book. It is
therefore important to work through the basics from the very beginning,
instead of jumping into the advanced features first.
(By the way: I don't mean this as an offence, but as an honest
recommendation how to proceed.)