Is Interface a "pattern" - or what is actually the intension of using interfaces

I got some feedback about the entry "Most Important Patterns" and especially the interface "pattern". I introduced the interface as pattern, but it is not a part of the standard GoF-family (I didn't meant the marker interface). The question remains, what is the intension of using interfaces? In Java there are some use cases for using it:

  • Providing an API
  • Encapsulating coarse grained functionality
  • Making implementations interchangeable
  • Hiding the technology
  • Exposing services (methods) 
  • ...

Considering the items above there is one common intension - exposing coarse grained functionality and hiding low level implementation. The opposite to the "interface" is a domain object. It is an objectoriented entity - without an explicit interface. In Java you will use for the realization of an entity just a class. The real power of domain objects, is the inheritance of behavior and state and polymorphic capabilities.

Interfaces emphasize the "serviceorientation" and provide a procedural point of view of a system. Domain Objects on the other hands provide a fine grained, and object oriented access to the business logic. So using interfaces do emphasize the services, methods, and processes.


NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License