Approach for creating class method

I am in the middle of a big dilemma.

In my app, we have tons of methods for selecting information based on different filters, an in many cases bringing different fields/attributes as well.

I thought of naming the methods based on the filter names (e.g. SelectEmployeeOnName (name) would bring all employees that have that name), other option would be to overload a lot of methods, but then this might not work in the cases where I had n methods with the same filter structure, differing only in the returned structure (the object).

Any idea on this




Answer this question

Approach for creating class method

  • worldhello

    not only could you enumerate your filters you could use a parameter list if you want to use multiple filters

    enum Filters
    {
    FirstName,
    LastName,
    //etc
    }

    public string SelectEmployeeByFilter(params Filters[] list)
    {
    //code
    }


    PS I hope there isn't a double-post, I was unable to edit my previous post so I tried to delete it, so yeah.


  • treckamerica

    There is nothing wrong with that naming. One of my rule in our code rule document is that method should be named by the job is doing. One of the rule is that you always should use full words and not shortcuts. But i will change that name a litle and by that code rules document every method that return someting will begin with Get and then with what type is returning and then some other thing. So the name for me will be GetEmployeeByName(string name). There is a rule that says, always be as descriptive as you can. If before developer needed to type every character in method name, now with this IDE you don't need to do that. But it's much easyer for new developer to realize what that method returns if name is self describing.

  • cashrolls2

    boban.s wrote:
    But i will change that name a litle and by that code rules document every method that return someting will begin with Get and then with what type is returning and then some other thing. So the name for me will be GetEmployeeByName(string name).

    To minimize the method count you should drop the Employee, why creatin one big class that contains of the find methods for all objects You should seperate this in diffent classes, for example:


    Customer customer = CustomerRepository.FindByName( "sande" );
    Order order = OrderRepository.FindById( 5122 );



    This way the object name OrderRepository gives the indication that it is about Orders.

    And don't use Get as prefix for the methods, following the Microsoft rules and FxCop you should not start with Get because, Get is for properties.

    boban.s wrote:
    There is a rule that says, always be as descriptive as you can. If before developer needed to type every character in method name, now with this IDE you don't need to do that. But it's much easyer for new developer to realize what that method returns if name is self describing.

    Can't agree more!



  • Anaray

    This is a shot in the dark but use an indexer which could take an enum value of the operation to execute. Code could look like this:


    enum Operations
    {
    Name,
    Weight,
    Status,
    // ...
    }

    public string this[Operation op]
    {
    get
    {
    switch (op) ...
    }
    }



  • Allen_Iowa

    Thanks to all !!! The comments and information were absolutely priceless...it has clarified my thoughts about naming convention.

  • Pete Orologas

    boban.s wrote:
    Some method are of course in Customer class like a method that returns all orders or transactions for current customer instance.

    You should never put Data Access Code in your Domain Objects! Because then there is no visable line and you can't reuse the classes elsewhere. And there is no need to, you want all the Orders of a Customer


    Order[] orders = OrderRepository.FindAllByCustomer( selectedCustomer );

    What if the requirements changes and you have to make the Collection classes accessable trought Remoting, then you only have to change the proxies in you Collection classes and in the UI Layer, there shouldn't be any Data Access. But there are Domain Objects in your UI Layer but you want to hide the Data Access so the programmers of the UI Layer can only use the UseCase/MVC classes.

    There is no golden rule and this is overkill in small applications that aren't N-tier, but it is my my humble opinion.



  • LynnOoi

    Thanks PJ for "Get" comment, you are right and i will change my code rule document. For the first comment, definitely you have a point, but i use collection class where those methods are and in this case it will be like CustomerCollection.FindByName(string name). Some method are of course in Customer class like a method that returns all orders or transactions for current customer instance.

  • Approach for creating class method