I feel it’s sometimes useful to create java objects with everything static, but use private/protected to control access.
Object state is implemented using struct. Operations on objects are implemented in static functions. C++ back to C.
I feel function pointers add lots of power.
Using nested if and instanceof.., you can implement complex logic in much fewer lines, and the logic is centralized and clearly visible.
If you refactor using OO design techniques, you often create many Types and scatter the logic.
Case in point — Error Memos workflow kernel. We could use factory, polymorphism, interfaces…
Case in point — chain of responsibility
Lots of interviewers asked me about my exception handling strategy. Here’s a tentative exception object design for a small project — Maintain just 2 custom exception classes.
1) MyCheckedEx.java — a big custom checked exception (by extending Exception.java?) containing an enum field. Each value represents a specific error condition.
2) MyUncheckedEx — a similar thing but unchecked (extending RuntimeException?).
Now the usage:
1) When you want a given error situation to always be handled in every *context* and never ignored, then register it in MyCheckedEx. Every place it can possibly occur, compiler will be your trusted friend to ensure it’s declared and handled explicitly.
2) things you put into MyUncheckedEx are nicely flexible, less strict. Callers (other developers) can choose to catch them or ignore them, silently escalating them to upstairs.
What about standard JVM exceptions? You can wrap them into your 2 exceptions. In particular, if you don’t like to handle many of the standard checked exceptions, you can wrap them in MyUncheckedEx. I think Spring wraps lots of Checked exceptions into unchecked. Conversely, you can wrap an unchecked exception into MyCheckedEx.
Another requirement — We often need a hierarchy of exceptions. Gmail uses labels instead of folders, so likewise, shall we declare some marker interfaces so an exception can be labeled as both validation and synchronization and billing exceptions? Will this beat a custom inheritance tree?
 a priority — i prefer fine-grained types of exception, for better control
 or int. You can use these in switch-case. I don’t like String.
non-priority — exception parent-child family. Unnecessary complexity.
This is just a java learner’s personal opinion — i feel constructors should avoid throwing checked exceptions. Traditional if/while/switch tests are more natural , more convenient, and more maintainable than throwing exceptions. Only in a few special scenarios should a constructor throw a checked exception.
My reasons against checked exceptions thrown from a constructor? My answer is long. A constructor returns null after throwing exception. The caller method has to 1) test for null before using the new object constructed. The caller also need to 2) try-catch the exception. Of course the constructor must 3) detect the invalid input before throwing. At least 3 tests.
Whenever possible, i would move Test #3 out of constructor into the caller, so constructor won’t return null nor throw checked exceptions. How to achieve this? One standard solution is a factory. Factory does Test #3 and handles the invalid condition. Factory may return null, so the caller still need Test #1. So 2 tests to perform.
This leads to an even simpler solution. If possible, the caller method should detect invalid input (Test #3) before passing it to the constructor/factory. 1 test only.
I guess this is rudimentary. Somehow, after programming java for years, i don’t always see the simplest solution. I think there are a lot of java design patterns, java idoms, common java constructs, such as throwing checked exceptions from constructors. I learnt these and didn’t know when NOT to apply them.
In my projects, i frequently face the decision to make a variable static or non-static. non-static is my default, first choice
j4: static vars aren’t easy to garbage collect
j4: instance vars can be accessed only after you instantiate the obj and after u get a reference, so i can better control access to my instance vars. Better encapsulation.
Key differences between static ^ instance methods
* static methods can only access static fields and static methods of this class, but many important “members” are non-static
* “public static” methods serve as “services” to clients (and deserve public service awards). Example: Arrays.*, Collections.*, Math.*
* static methods can run before the constructor ==> Many common operations in a class must be static — main(), getInstance()
* abstract method can’t be static. See other posts for the complicated reasons.
* “synchronized” has different meanings
Strategy patterns allows you to define a family of interchangeable algorithms, to be selected at runtime. In extreme circumstances, a new algorithm is to be created and to be added immediately without jvm restart. This would be a higher level of flexibility.
Perhaps the highest level of flexibility is offered by a DB containing classnames in the “family”. After you create a new algorithm, you insert its classname into the DB.
Class c = Class.forName( “com.myPackage.Myclass” );
Thing t = (Thing)c.newInstance( );
Also see detailed sample code in http://www.javaworld.com/javaworld/jw-08-2001/jw-0810-extend.html
static boolean flag=false;
if ( System.getProperty(“d”)!=null ) flag=true;
if ( System.getProperty(“d”) == null ) flag=…..;
The 2nd version — rather unreadable — seems to set the default, but default is usually and best set on variable declaration, which is more readable.