Is there a specific design pattern that describes the scenario where a non-abstract default implementation is provided that implements all or some of the method
It's also used in Swing (WindowAdapter, which implements WindowListener). It's only a convenience adapter, you only have to define 1-2 methods in this way to have a useful windowlistener. This is indeed an instance of the Adapter pattern, also shows the power of the abstract classes. It's even an example to illustrate why multiple implementation inheritance is useful sometimes.
As for the regular Design Patterns, in the Temlate Method you can define hook operations, which may be overriden (unlike abstract methods, which must be), but the default behaviour (usually the NO-OP) is meaningful too.
I have seen this design used in spring where they have a class named FlowExecutionListenerAdapter which saves you implementing all the FlowExecutionListener operations.
However, it does sound like the Null Object Pattern too. However I feel it sits better in the Adapter world purely because it changing the behavour of the interface by allowing you only to implement the bit you want...but its a tough one.
I'm sure this question has been asked before?
This sounds similar no? might be worth a read.
You should follow different design principle : interface-segregation principle
The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use. Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one sub module.
You should not implement MORE And you should not implement LESS
Have a look at related SE questions for more details.
The Interface Segregation Principle
Interface Segregation Principle- Program to an interface