2012-10-13 188 views
6

Estoy aprendiendo C# y estoy tratando de entender cuándo usar clases y cuándo no.C# banco ejemplo - clase para clientes - qué para retiros, depósitos, etc.

Si estaba escribiendo una aplicación para un banco, sé que usaría clases para clientes que incluirían su nombre, número de cuenta, saldo, etc. ¿Utilizaría una clase estática para los métodos que se depositarían en su cuenta? , retirar, cambiar su dirección, etc. ya que solo necesito escribirlos una vez?

Además, ¿qué usaría para realizar un seguimiento de cada objeto del cliente? Tener 2.000 clientes:

exampleName = new Customer(); 

en mi código no parece correcto. Todavía no estoy en el punto de aprender bases de datos y estoy aprendiendo clases.

+0

@slugster Fair point. – nickhar

+1

La lista y otros tipos de colecciones son importantes. Consulte también MSDN: http://msdn.microsoft.com/en-us/library/6sh2ey19.aspx – varg

Respuesta

5

Tener una base de datos sería lo ideal, pero en la media hora que usted podría utilizar un IEnumerable para mantener sus objetos de clientes, así:

List<Customer> myCustomers = new List<Customer>(); 
myCustomers.Add(new Customer {Name = "Bob", Address = "123 Anywhere St." }); 

a continuación, puedes pasar a la lista de alrededor de donde sea necesario.

lo general a continuación, tendrá una propiedad de la clase Customer que mantiene las cuentas:

public class Customer 
{ 
    public Customer() 
    { 
     _accounts = new List<Account>(); 
    } 

    public List<Account> Accounts 
    { 
     get { return _accounts; } 
     set { _accounts = value; } 
    } 

    private List<Account> _accounts; 
} 

Y así sucesivamente. Tenga en cuenta que estoy manteniendo esto simple y haciendo las cosas de la manera más larga y descriptiva como usted es un principiante.

Usar una lista de elementos de esta manera es una buena manera de comenzar porque los usará naturalmente cuando llegue a utilizar una base de datos; recuperará los conjuntos de resultados de la base de datos y luego los traducirá en listas de objetos comerciales.

En cuanto a usar métodos estáticos para hacer lógica de negocios como ajustar saldos, cambiar direcciones, etc., para usted en este momento no importa. Si está utilizando herramientas como Resharper, le molestará con sugerencias como esa, pero en su caso puede ignorar con seguridad esa particular. Lo que debe buscar es mantener todo lo más autocontenido posible, evitar la fuga de datos y la pérdida de responsabilidades entre los objetos; esto es solo una buena disciplina de codificación y una buena forma de evitar los errores causados ​​por la falta de codificación.

Una vez que tenga la funcionalidad establecida y en funcionamiento, es posible que desee mover algunas funcionalidades a clases de estilo "auxiliares" estáticas. Esto está absolutamente bien, pero tenga cuidado: las clases de ayuda son fantásticas y todo, pero puede convertirse rápidamente en un antipatrón si no mantiene esa disciplina de codificación.

3

No necesita utilizar una clase estática o métodos estáticos para escribir solo los métodos una vez. Puede o no puede tener sentido para hacerlo, pero esto es una forma perfectamente válida para escribir los métodos without repeating yourself:

public class Customer 
{ 
    //properties, constructors, etc. 

    public virtual void Deposit(decimal amount) { } 
    public virtual void Withdraw(decimal amount) { } 
    //etc 
} 

Esto también le permite hacer uso de polymorphism, por ejemplo,

public class BusinessCustomer : Customer 
{ 
    public override void Deposit(decimal amount) { //some other implementation } 
} 
0

lo que para retiros, depósitos, etc

Aquellos serían llamados Transacciones.

0

Las clases estáticas se usan cuando no se van a crear instancias de objetos. Se obtiene un "ejemplo" de esa clase - no se puede hacer cosas como:

MyStaticClass m = new MyStaticClass(); 
m.SomeFunc(); 

cuando se tiene una clase estática. En cambio, lo usarías usando el nombre de la clase en sí. Algo como:

MyStaticClass.SomeFunc(); 

¿Qué utilizaría para realizar un seguimiento de cada objeto del Cliente? Podría usar algún tipo de colección para contener esto. De acuerdo, en un sistema real habría algún tipo de pieza de persistencia, probablemente una base de datos, para contener los datos. Pero se podría acaba de hacer algo como:

IEnumerable<Customer> Customers = new List<Customer>(); 

Y a continuación, añadir a sus clientes a esa lista

Customers.Add(new Customer() { ... }); 

Volver a la pregunta sobre los métodos estáticos ...

Por lo tanto, el problema aquí es que no va a hacer referencia a los miembros de la instancia en un método estático, por lo que no usaría métodos estáticos para actualizar la dirección de un cliente en particular. Asumiendo que su clase Cliente parecía:

public class Customer 
{ 
    public string Address { get; set; } 
} 

No se podía utilizar un método estático como

public static void SetAddress() 

ya que cada cliente (presumiblemente) tiene una dirección diferente. No se pudo acceder a la dirección del cliente allí porque no es estático. ¿Obtén éso? En cambio, usaría un método estático si quisiera hacer algo que no necesitara lidiar con datos de instancia. Utilizo métodos estáticos para cosas como funciones de utilidad.

public static double ComputeSomething(double someVal) { ... } 

Aquí, la función ComputeSomething puede ser llamado por nadie como:

var result = MyStaticClass.ComputeSomething(3.15); 

La lección aquí es que estáticas clases no se utilizan para crear instancias de objetos, sino que se utilizan realmente como una contenedor conveniente para mantener las funciones. Las funciones estáticas son las que pueden estar en una clase no estática pero no pueden acceder a ninguno de los datos de instancia.

Un lugar donde se usaría una función estática sería para el patrón Singleton. Haces que el constructor no sea público para que la gente no pueda llamarlo, y en su lugar proporciona un método estático en la clase para devolver la única instancia de la clase. Algo como:

public class MySingleton 
{ 
    private static MySingleton instance; 

    private MySingleton() {} 

    public static MySingleton Instance 
    { 
     get 
     { 
     if (instance == null) 
     { 
      instance = new MySingleton(); 
     } 
     return instance; 
     } 
    } 
} 
0

Esto está destinado a ser además de las otras respuestas. Este es un ejemplo de polimorfismo con interfaces.

public interface IDeposit { 
    void Deposit(decimal amount); 
} 

public interface IWithdraw { 
    void Withdraw(decimal amount); 
} 

public class Customer : IDeposit, IWithdraw { 
    public void Deposit(decimal amount) { throw new NotImplementedException(); } 
    public void Withdraw(decimal amount) { throw new NotImplementedException(); } 
} 

public class DepositOnlyATM : IDeposit { 
    public void Deposit(decimal amount) { throw new NotImplementedException(); } 
} 

Mantiene los conceptos separados, y permite implementar múltiples interfaces, o solo una. Con los enfoques de herencia de clases, solo obtienes uno, y obtienes todo. Inevitablemente terminas con spaghetti en mi experiencia porque las subclases quieren algo del comportamiento, pero no todo.

0

Recomendaría en lugar de entrar en los detalles de implementación de inmediato que primero escriba algunas historias de usuario simples para su ejemplo de banco. Por ejemplo

  1. Como un cliente me gustaría abrir una nueva cuenta para que pueda realizar depósitos o retiros

Justo en ese requisito, podemos imaginar un par de clases (el cliente y la cuenta) . A partir de ahí, simplemente se descompone funcionalmente lo que el cliente debe hacer y lo que debe hacer la cuenta.

He encontrado que el libro "El proceso de pensamiento orientado a objetos" es una buena lectura y ayudará a responder algunas de las preguntas sobre "cuándo hago esto frente a eso".

¡Buena suerte y diviértete!

Cuestiones relacionadas