Recommendations for Abstract Classes vs. Interfaces: Visual Basic and Visual C# Concepts

Recommendations for Abstract Classes vs. Interfaces: Visual Basic and Visual C# Concepts [source: MSDN]

On abstract classes: “An abstract class is a class that cannot be instantiated, but must be inherited from. An abstract class may be fully implemented, but is more usually partially implemented or not implemented at all, thereby encapsulating common functionality for inherited classes.”

On interfaces: “An interface, by contrast, is a totally abstract set of members that can be thought of as defining a contract for conduct. The implementation of an interface is left completely to the developer.”

Abstract classes vs. interfaces: When does it make sense to choose an abstract class over an interface?

Abstract classes vs. interfaces: When does it make sense to choose an abstract class over an interface? [source: javaworld]

“Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn’t know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.”

Java accessor visibility

Java accessor visibility: When to make accessors public, and when to keep them private

“So how do you determine the proper visibility of an accessor method? My experience is that you should always strive to make accessors protected, so only subclasses can access the attributes. You should try to make accessors private if subclasses don’t need access to the attribute. Only when an external class or object needs to access an attribute should you make the appropriate getter or setter public. It is quite common for the visibility of corresponding getter and setter methods to be different: in the class Seminar, you see the getTitle() method has public visibility, yet setTitle() has private visibility.”

Wafer

Wafer is a research project which compares the many open source web application frameworks which are available using a common example application. This research project is designed to compare the application frameworks on a level field by specifying an example application so that the application features become irrelevent and the merits of each framework becomes the focus.