Dave Lorde

It's really not clear to me what you're trying to achieve, but if you want to exit the loop when there is an exception, put the loop inside the try block (so the catch is outside the loop). If you want to continue looping after an exception, put the try...catch inside the loop.

Rajesh Nagaraju wrote:

Dave Lorde wrote: There are various different GC strategies available (you can set them on the command line).

Dave, correct me if I am wrong this is only from jdk1.4

I don't recall, but I doubt that many people are still developing with 1.3 or earlier versions.

This covers the GC options: Tuning Garbage Collection With Java 5

It's not a simple consideration. I see it as a mix of 'Best Practice' and 'Slippery Slope'. There's no doubt that public access to class internals is a major risk to robustness and reliability, it increases coupling and compromises encapsulation and refactoring regardless of IDE facilities, and it makes testing, instrumentation, and dependency injection far more difficult. In a large application, especially with team development, keeping a high standard of code quality is essential, and once you start lazy practices, they can easily become 'lost' and forgotten in the code. Coding is still a mix of the technical with art/craft, and it seems to me that no self-respecting craftsman would be happy to release poor quality code. There are situations such as DTOs where pure data structures without operations are passed around, but as has been mentioned, these are increasingly expected to behave as Java Beans by framework tools, so the argument for public data even in these special situations is weakening.

Lavanya Halliwell wrote:so I think I understand what you're saying, and that it's will call the GC when the runnable class or thread finishes or goes out of scope.

The class instance becomes eligible for garbage collection when there are no more references to it, but that doesn't mean it will be garbage collected. There are various different GC strategies available (you can set them on the command line), but there are no guarantees when or if an object will be GC'd. You can programmatically request a GC scan, but it's just that - a request; the JVM can ignore it. While there is memory available, garbage collection isn't a priority.

The method without the <T> following the 'static' is a generic method in a generic class, where the class has been declared to use 'T' as a generic type. Because the class declares that it's using 'T', the method can just use it without declaring it.

The method with the <T> following the 'static' is a generic method in a class that has not declared 'T' as a generic type. You can have a generic method in a non-generic class. The <T> declares that the method will be using 'T' as a generic type. The method needs to declare this because the class doesn't.

Disambiguation - it's the same solution as in C++ : you have to specify which of the constants you want to use:System.out.println(two.i); // or System.out.println(one.i);Incidentally, you'll find it a lot easier to follow code if you use the Java naming conventions - type names begin with an uppercase letter, method and variable names begin with a lowercase letter.

umasankar puranam wrote:Hi Dave Lorde,

Could you please give me sample non-recursive code in Java to delete all files, directories, and sub-directories in a drive?

Hi Umasankar Puranam,

No, I couldn't. It is possible but pointless. If you would like to do it for yourself, by all means go for it, I'm sure you'd learn a lot. Try it with a very simple example to start.

In principle, any recursive procedure can be achieved non-recursively, by using an explicit stack instead of the implicit stack of recursion.

See Convert Recursive to Non-recursive.

pete reisinger wrote:...
I thought that the second option is better (as you said, floating point rounding) but could be slower - which doesn't really matter (early optimization = evil)

In general, don't worry about performance until you have hard evidence that it is a problem. Pick the best option for the business requirement, and if there's a performance problem, you can optimize after running a profiler to find exactly where and what the bottleneck is.

Well I wouldn't start from there if I had the choice (why start with a float?), but I think I prefer the second option - format to String, then parse, because this handles any floating point rounding nastiness for you with no effort, whereas just casting to int will simply truncate the value.

Int will handle quite large values, but are you certain that you won't exceed its range? The usual way to manage money is with BigInteger.

YMMV.

jose chiramal wrote:Also I read this point "If you need to change your design frequently,
you should prefer using interface to abstract."

In the code ranch faq i read this : "use an interface if you're sure the API is stable for the long run"


Aren't both these statments contradictory ?

A good question - I think it means that 'design' in the first guideline is not the same as 'API' in the second. The thing about interfaces is that they define what a type is and what it does - that's what the API specifies, known as the 'contract'. How each object does what the API specifies is something else. But if you haven't decided exactly what a type is and what it does, it's not ready for use. Once an interface is specified, it should not change.

The design (as used in the first guideline) is about how you use the interfaces in your application - how you implement them and how you get the implementations to interact with each other. Interfaces give you great flexibility because you can implement them however you want, and if you only pass interfaces around within your application, you can add new implementations with minimal code changes.

jose chiramal wrote:I have a class Car(it has methods enginespecs and color), and there are two sublcasses to it, BMW and Toyota

In this scenario how do I know whether to use an interface or class hierarchy.

This is not as simple an example as you may have intended, because from one point of view BMW and Toyota are not strictly cars, they are manufacturers of cars, so BMW and Toyota Cars could be seen as a Car subclass of, say, RoadVehicle, that has BMW or Toyota as its Manufacturer or Make attribute. So much depends on what use the class hierarchy is intended for - you always have to compromise because you can only partially represent the real world in an object hierarchy, and only those aspects that are relevant to your application. For example, suppose you wanted to divide Car into subtypes such as FourByFours, Compacts and Saloons - how would that work if BMW and Toyota were subclasses of Car? I'm not saying it's not correct, just that it needs careful thought in terms of your current and possible future requirements.

At work, we have a large data entry & processing server application with a complex client GUI, and we have spent a lot of time over the last year refactoring it to make much more use of interfaces because they make it much easier to test, refactor, extend & enhance, and to use DI (Dependency Injection) frameworks like Spring.

My own rule of thumb for when to use interfaces is to always use them wherever you have a type in your model. It may seem like overkill, but I've come to the view that application design should be done entirely in terms of interfaces. The main problem with using abstract classes instead of interfaces is the reduction in flexibility it gives you - instead of multiple inheritance you have single inheritance - you're stuck with the implementation of that abstract class, even if it turns out to be unsuitable, whereas you can always add a new and completely different implementation of an interface. You can use abstract classes for shared implementation used by subclasses. By using interfaces throughout, you lose nothing and gain clarity and flexibility.

When passing parameters and returning values, always use interfaces, and all public methods should be implementations of interface methods. You only need to see the concrete classes when you're creating instances of them.

So my approach for your example would probably start with interfaces Car and Manufacturer. AbstractCar would implement the Car interface with all code common to all cars, and would contain a Manufacturer constant. If there were subtypes of Car, such as FourByFour, Compact and Saloon, I'd make them interfaces too with abstract implementations. This way, you end up with an interface hierarchy and a parallel implementation hierarchy, something like this:interface Car { Manufacturer getMake(); EngineSpecs getEngineSpecs(); Color getColor(); void respray(Color color); } // Let's have engine specs for each car type enum EngineSpecs { Compact, Saloon, FourByFour } enum Manufacturer { BMW, Toyota; String getName() { return name(); } } abstract class AbstractCar implements Car { private final Manufacturer make; // this can't change private EngineSpecs engineSpecs; private Color color; public AbstractCar(Manufacturer make, EngineSpecs es, Color color) { this.make = make; engineSpecs = es; this.color = color; } public Manufacturer getMake() { return make; } public EngineSpecs getEngineSpecs() { return engineSpecs; } public Color getColor() { return color; } public void respray(Color color) { this.color = color; } } interface FourByFour extends Car { //... } interface Compact extends Car { //... } interface Saloon extends Car { //... } class FourByFourImpl extends AbstractCar implements FourByFour { public FourByFourImpl(Manufacturer make, Color color) { super(make, EngineSpecs.FourByFour, color); } ... } class CompactImpl extends AbstractCar implements Compact { public CompactImpl(Manufacturer make, Color color) { super(make, EngineSpecs.Compact, color); } ... } class SaloonImpl extends AbstractCar implements Saloon { public SaloonImpl(Manufacturer make, Color color) { super(make, EngineSpecs.Saloon, color); } ... } ... // how you might use them: public static void main(String[] args) { // Create a red BMW saloon, a blue Toyota compact and a white BMW 4x4 Saloon bmwSaloon = new SaloonImpl(Manufacturer.BMW, Color.RED); Compact toyotaCompact = new CompactImpl(Manufacturer.Toyota, Color.BLUE); FourByFour bmw4x4 = new FourByFourImpl(Manufacturer.BMW, Color.WHITE); ... }Note that I use AbstractXxxx for abstract superclasses and XxxxImpl for concrete classes that implement an interface. It makes it easier to write and follow the code.

This is just an example of how I use interfaces & abstract classes, it's not meant to be a 'correct' design for any particular application.

Don't quite see what your question is here... can you be more specific?

You can simplify and clarify that:if(f3.isVisible()){ f3.setVisible(false)); } f2.setVisible(true)); ... if(f2.isVisible()){ f2.setVisible(false)); } f3.setVisible(true));Then simplify further:switchFrames(f3, f2); ... switchFrames(f2, f3); ... void switchFrames(JFrame oldFrame, JFrame newFrame) { if (oldFrame.isVisible() { oldFrame.setVisible(false); } newFrame.setVisible(true); }In fact, you don't even need the 'if' statement - it's OK to call setVisible(true/false) on the frame whether it's visible or not:switchFrames(f3, f2); ... switchFrames(f2, f3); ... void switchFrames(JFrame oldFrame, JFrame newFrame) { oldFrame.setVisible(false); newFrame.setVisible(true); }

Paul Clapham wrote:Let's suppose you implement this business rule ("The hire date can't be before the date the company was formed") by having this Date object throw an exception. That's certainly valid Java code, and it might be the right thing to do in some contexts.

Yes, doing it that way suggests the class should be called HireDate and be a subtype of Date - which doesn't look sensible For a date constructor you'd generally be throwing an exception if the parameters can't construct a valid date (e.g. 0 < month value < 13) rather than restricting the date itself to an arbitrary range. Business rules are not generally involved in type specifications that way.

So yes, you can certainly implement your constructor as you originally asked. From a technical point of view, that is. But there are a lot of situations where you shouldn't implement it that way, instead having something else validate the data before calling the constructor.

Agreed.