How is an enum class E different from regular classes?
* static field? ok
* inst field? ok
* static method? ok
* inst meethod? ok
* static methods returning an instance of E? ok
* inst methods returning an instance of E? ok
#2 difference — flat tree. enums can’t form a class hierarchy. All enum classes are on the same level — all leaf-nodes under the same parent.
* can an enum E extend ..? E’s superclass is always java.lang.Enum
* subclasse E? no
* E implementing interfaces? ok
#1 difference — constructor:
* constructors? private only => not subclass-able
* how many instances of the class can be created in a JVM? If there are 5 enum values declared, those are the only instances. All the pointers of type E point to one of the 5 instances.
* constructor with arg? ok
* no-arg constructor? ok
Say you have an Account.java representing one row in Account table. You have an AccountDAO.java that read/write the table.
Q: Shall Account.java HAS-A AccountDAO instance?
A: I feel Account.java should not import AcountDAO at all. Acocount.java should be compilable without AccountDAO.java. Assumption is, Account.java is a more generic class. It should be usable in other projects (web, xml serialization, file-based …) without database.
Bottom line — If you want AccountDAO to be compile-time dependent on Account.java, then don’t have the reverse-dependency. DAO is one layer above the DB entity objects.
If Account table relates to Customer and Branch tables, it’s perfectly legitimate and perhaps best practice to use HAS-A between these classes. I think Hibernate and many ORM systems do that. These classes exist on the same “layer” so compile-time dependency is perhaps tolerable. To reduce compile-time dependency, use interfaces rather than classes.
What does it mean when a java developer says
“download xyz jar”
“Give me your java api”
“You own that api”
“use this java toolkit”
They are referring to some java classes (or interfaces), usually organized into a package. This toolkit is maintained by one team (owner) to be used by other teams.
Now, good OO design requires encapsulation, so there are usually a limited number of entry points to the toolkit. I mean the first thing you write to reference the toolkit. I think there are only 2 entry points — static methods and constructors.
In some toolkits, api methods are instance methods. Question is how do you get the first instance from this toolkit? The entry points are all about instantiation.
Factory are often static methods.
* a special map instance field to hold all such data. Map of Objects, so casting needed everywhere.
* (laziest) instance field? reserved for instance attributes. Don’t abuse.
* (laziest) static field? reserved for class attributes. Don’t contaminate.
* return a collection? A bit clumsy but recommended by many.
* best option: avoid sharing. Stick to local vars if possible.
* 2nd best: sometimes the shared variable really belongs to another class. That class/object perhaps is already shared between your methods. Essentially use that object as a courier. More work than the laziest.
Often u make it an interface but there are a few justifications
Q: I think an interface must be public ??
A: non-public interface can be nested inside a class.
* all fields in interfaces must be public static final
* all methods in interface must be public
* #1 justification: Say you plan to add concrete methods to your abstract class. You make it abstract now (instead of interface) to forbid subtypes extending something else. Consider the nightmare — U make it an interface, a subtype extends something else, and now u want it to extend your abstract class instead …. the required change could be huge and painful.