Interesting, you're being asked the "why" not the "what" for these...
Difference between Abstract class and interface.
An abstract class lets you define default behavior, while an interface does not. If the deriving types should share some common behavior then an abstract class is preferred. If they share common interface then...yeah.
More subtly, an interface is a contract on a type that states what it is able to respond to, but nothing about what it is. An abstract base class says something about what derived types actually are, and what they are not because they can only inherit from the one base type.
As a little addendum to this post: the two are not mutually exclusive. I have used an interface to define a contract I'd like some objects to use, then implemented that interface on a base class that my several objects will derive from. The abstract base provides some helper methods that would be common to that family of types, but not part of the public behaviors of those objects. Also the interface could be reused by any other types that wanted to expose that behavior, but didn't want the baggage of my base class.
In a language that allows "free standing" global methods and static methods on objects, the reason to prefer the latter is that it provides 1) better scoping and 2) context.
Say you wanted a method CreateNew() to act as a factory for some type. Making it static on that type makes it obvious what it does: Dogs::CreateNew(). The alternative, CreateNew(Type t) tells you nothing about what limitations the method may have. Worse, it would be a nightmare to maintain.
Honestly, I very rarely come across methods or classes I would definitely never want someone to extend, and frequently come across other people's code I wish I could extend but can't due to
That said, good candidates include:
Any method (or class) with dangerous, complex, or slow side effects.
Any method that other classes or methods rely on operating in a specific way (which is bad design, but it is a use case).
Code that no one should ever need to extend, like simple utility methods. But again, if there's no harm in allowing it, why bother locking it?
A constructor is for initializing an object's private state prior to it being used. Any variables that need setting, objects that need making, or anything that needs to be done before an object is usable should be done in the constructor if possible.