¿Debería instanciar una colección o heredar de la colección?

Question

Me he hecho esta pregunta varias veces al crear clases, particularmente aquellas que involucran colecciones, pero nunca he encontrado una respuesta satisfactoria. Es una pregunta de diseño OOP.

Por ejemplo, en un programa de registro de chequera, digo que tengo una clase de BankAccount. Las cuentas bancarias contienen datos que incluyen el nombre de la cuenta, el tipo de cuenta (enumeración de verificación, ahorro, ...) y otros datos, pero lo más importante es una colección de Adjustment s (depósitos o retiros) en la cuenta.

aquí, tengo dos opciones para mantener una colección de los ajustes:

1. crear instancias de una colección y mantenerlo como un miembro de la clase CuentaBancaria. Esto es como decir "Cuenta bancaria tiene una colección de ajustes".
2. Heredar de la colección. Esto es como decir "Cuenta bancaria es una colección de ajustes".

Creo que ambas soluciones son intuitivas, y, por supuesto, ambas ofrecen algunas ventajas y desventajas. Por ejemplo, la creación de instancias permite que la clase herede de otra clase (en idiomas que permiten solo una única clase base), mientras que heredar de la colección facilita el control de Agregar, Eliminar y otros métodos sin tener que escribir métodos sustitutos para "envolver" ' aquellos.

Entonces, en tales situaciones, ¿cuál es un mejor enfoque?

Answer 1

Para mí, una cuenta bancaria tiene una colección de ajustes. Una cuenta bancaria no es una colección de ajustes, porque "es" mucho más que eso: también "es" un nombre y un tipo, etc.

Entonces, en su caso (y casos similares), Te sugiero que agregues una colección dentro de tu clase.

En caso de duda, evite la herencia. :-)

Puedo argumentar esto más. Para utilizar la herencia correctamente, la subclase debe satisfacer Liskov's substitution principle; esto significa que, en su caso, BankAccount debe ser un tipo válido en cualquier lugar donde se espere un Collection. No creo que sea así, porque Collection probablemente expone métodos como Add() y Remove(), mientras que usted querrá ejercer cierto control sobre la adición y eliminación de ajustes de su cuenta bancaria en lugar de dejar que las personas los agreguen y eliminen libremente.

Answer 2

Personalmente, yo diría que BankAccounttiene colección de Adjustment. Probablemente tenga otras propiedades que no sean exclusivamente sobre lo que se ha depositado o retirado (cliente, tipo de cuenta bancaria, etc.).

En términos de diseño, mi objeto BankAccount expondría una propiedad de carga tardía del tipo Adjustments.

En términos de uso dentro del código, instanciaría la cuenta bancaria, y si necesitaba saber qué había entrado y salido de la cuenta, usaría la propiedad expuesta.BankAccount sería el principal objeto, responsable de proporcionar los ajustes relacionados solo con la cuenta instanciada.

Answer 3

Crea una instancia, definitivamente.

Acepto que los otros pósters sobre Cuenta bancaria son "más" que solo una colección de otros artículos. O tal vez hayas elegido un ejemplo que realmente grita por "instanciar".

Ejemplos:

• ¿Qué pasa si su cuenta bancaria necesita una segunda colección de objetos completamente diferentes? (Ejemplo: colección de personas que pueden operar en ella, como esposo y esposa, por ejemplo, cobro de tarjetas de crédito, cuentas paypal o cualquier otra cosa que pueda "operar" en su cuenta bancaria).
• Dependiendo del idioma, una colección expone demasiada información: si otro objeto necesita acceder a los ajustes ... digamos para mostrar su historial de movimientos en una página web expone automáticamente su "colección" para inyección, eliminación, etc. .

Answer 4

Creo que estar demasiado atrapado en la semántica como "esto es más es-a o tiene-a" es un poco peligrosa - al final del día, lo que importa es lo bien su diseño resuelve el problema , qué tan fácil de mantener es, etc. De hecho, personalmente, un punto de inflexión en la forma en que entiendo la programación orientada a objetos fue soltar "objetos como sustantivos". Los objetos son, cuando se llega a él, una abstracción de un nivel arriba de una función, nada más o menos.

Esta fue una forma larga de decir "tiene una". :-) Subclases es complicado, usar es fácil.