# Abstract classes and methods
* Author(s): David Scrève
## Introduction
When developing framework and reusable, we need to develop classes that are partially
abstract with partial implementation. Protocol and protocol extensions provide this, but
they cannot have attributes as classes have.
A partial class combines the behavior of a class with the requirement of implementing methods
in inherited class like protocols.I tend to agree that adding abstract methods (and classes) is the right thing to do. OOP is an important part of Swift, and is a great way for modeling certain classes of problems.
I’m not nearly as convinced that it’s worth doing. It’s a small feature with a small win, and I tend to think that protocols are a better answer for most problems for which one would reflexively reach for an abstract class.
I wonder if we could simplify our initializer model if we had this, for example, could “required" initializers go away?
No, it doesn’t help with required, but the differences between “abstract” and “required” would be sure to cause confusion. “abstract” means “some class along the inheritance path below me must implement this”, whereas “required” means “every class along the inheritance path below me must implement this."
- Doug
···
On Jan 9, 2016, at 11:02 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Jan 7, 2016, at 9:55 AM, David Scrève via swift-evolution <swift-evolution@swift.org> wrote: