¿Por qué y cuándo crear subclases de widgets GTK?

Si buscamos, por ejemplo, en GeditTab, contiene --- por composición --- a GeditView. GeditView es una subclase de GtkSourceView. En su lugar, GeditTab podría usar por composición directamente un objeto GtkSourceView y mover el código de GeditView a GeditTab. Pero, por lo general, sucede o debería ocurrir exactamente lo contrario.

Cuando la base de código de una aplicación GTK aún es pequeña, por ejemplo, si comienza a escribir un equivalente de GeditTab, puede crear un objeto GtkSourceView directamente en GeditTab y almacenar la GtkSourceView objeto en una variable de instancia. Luego, al implementar nuevas características, agrega nuevas funciones que usan casi exclusivamente la variable de instancia GtkSourceView. Incluso puede tener funciones static que toman directamente un argumento GtkSourceView en lugar del parámetro GeditTab self. También puede almacenar datos adicionales útiles solo para las funciones relacionadas con GtkSourceView. Si la clase GeditTab aún es pequeña (por ejemplo, 500 líneas de código) y no contiene muchas variables de instancia, no hay problema. Por otro lado, si la clase GeditTab se vuelve más grande (por ejemplo, más de 2000 líneas de código), entonces probablemente sea una señal de que la clase debería delegar parte de su trabajo a una nueva clase; en nuestro caso, GeditView. Tenga en cuenta que 2000 líneas de código para una clase pueden estar bien, no hay un límite claro sobre cuándo se debe dividir una clase. Pero si la clase GeditView resultante contendría al menos varios cientos de código no estándar, probablemente sea una buena idea hacer la refactorización.

De lo que se trata OOP es de empaquetar datos y comportamiento juntos, y delegar parte del trabajo a otras clases. La herencia de clases tiene sentido cuando queremos agregar más comportamiento a una clase existente, con posibles datos adicionales relacionados con el comportamiento agregado. GeditView es una subclase de GtkSourceView porque GeditView es a GtkSourceView; es decir, GeditView opera con los mismos datos base que GtkSourceView. Además, permite a GeditTab delegar parte de su trabajo, con el objetivo de tener clases más pequeñas y manejables. Más pequeño de dos formas: menos código y menos variables de instancia.

Por lo tanto, durante la vida útil de una aplicación GTK, el programador a menudo necesita refactorizar el código, crear nuevas clases y delegar más trabajo. Lo contrario puede suceder cuando el código de la aplicación se mueve a la biblioteca subyacente; por ejemplo, si todas las características de GeditView se agregan a la clase GtkSourceView; en ese caso, la subclase GeditView ya no tiene sentido.