Abstract Classes « Class « Java Articles

1.	Build Deploy
2.	Class
3.	Core Library
4.	Data Types
5.	Database JDBC
6.	Design
7.	Development
8.	File Input Output
9.	Graphics Desktop
10.	J2EE Enterprise
11.	J2ME Wireless
12.	JVM
13.	Language
14.	Library Product
15.	Network
16.	Security
17.	SOA Web Services
18.	Test
19.	Web Development
20.	XML

Java Articles » Class » Abstract Classes

1. Abstract classes and interfaces practicum javaworld.com

A recurring request asks to see a complete example of using interfaces and abstract classes. Based on the feedback, the original answer proved a bit too theoretical, so in this follow-up Java Q&A;, I will bring the discussion down to earth by presenting a framework that employs both interfaces and abstract classes.

2. Maximize flexibility with interfaces and abstract classes javaworld.com

To lay the groundwork necessary for a clear discussion, I review Java class and interface constructs from both type and implementation-centric viewpoints. As detailed in my earlier article, "Thanks Type and Gentle Class" (JavaWorld, January 2001), classes and interfaces establish a system's type hierarchy, whereas only classes establish the implementation hierarchy. Classes divide into two types: concrete and abstract.

3. Abstract classes vs. interfaces javaworld.com

In Java, under what circumstances would you use abstract classes instead of interfaces? When you declare a method as abstract, can other nonabstract methods access it? In general, could you explain what abstract classes are and when you might use them?

4. Use abstract classes to provide default behavior or define a small family artima.com

It's really a tight-knit family thing. In the Java programming language, people can always use inner classes, which is a short hand of using composition, to get around multiple inheritance of implementation. If it feels more like a small family, go for the abstract class.

5. Versioning, Virtual, and Override artima.com

A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual."

6. Designing with Interfaces & Abstract Classes developer.com

In the previous column, you started your exploration of interfaces. In this installment, you delve deeper in interfaces and explain how they relate to abstract classes.