Click here to Skip to main content
15,886,026 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I have a question regarding passing object to method or creating an object within the method using key value. Which is a better approach ?

Consider below code. In BuilderOrder class there is a method called GenerateKey which needs to access BuilderMaster object. Is it a good idea to pass BuilderMaster object directly as a parameter to the method or pass key value and create BuilderMaster object within method.

C#
public class BuilderMaster
{
    public DTO.BuilderMaster GetBuilderMaster(string systemNo)
    { 
        // rerurn builderMaster object
    }
}

public class BuilderOrder
{
    //Option 1 : Pass systemNo value from UI and create object .
    public bool GenerateKeys(string systemNo,int  noOfKeys)
    {
        BuilderMaster objBuilderMaster = new BuilderMaster();
        DTO.BuilderMaster objThisBuilder =  objBuilderMaster.GetBuilderMaster(systemNo);

        //use objThisBuilder's properties during key generation process.
    }

    //Option 2 : Pass object from UI
    public bool GenerateKey(DTO.BuilderMaster objThisBuilder, int noOfKeys)
    {
        //use objThisBuilder's properties during key generation process.
    }
}


Option 1 creates tight coupling while Option 2 does not.

Now consider GenerateKey is method exposed by a web service which is being called by a web application running on a different machine. Option 1 creates a lighter request object compared to option 2 as in option 1 you are only passing primitive types while in Option 2 you are passing a whole builder master object.

Which is a better approach ?
Posted
Updated 29-Oct-14 14:46pm
v2
Comments
Sergey Alexandrovich Kryukov 29-Oct-14 20:45pm    
It has nothing to do with design patterns.
—SA
virang_21 29-Oct-14 20:47pm    
You are right.. it is more like implementation option to choose from

That's not actually a Design Pattern question.

My answer is "pass the object".

0) The other way couples the method to the class too tightly.
1) If you pass in the object -- and especially if you use an Interface -- then you can pass in other/derived classes. Or mocked objects!
2) Modularity -- get then set.
3) Consider what happens in the future if there's something else to set.
 
Share this answer
 
v2
Comments
Sergey Alexandrovich Kryukov 29-Oct-14 20:47pm    
5ed, but I'm not sure OP can get it. Understanding of your arguments takes understanding of OOP, reference objects, general project maintenance, and so on...
—SA
BillWoodruff 29-Oct-14 23:05pm    
+5 Seems as clear as possible, given that we don't know what's going on behind the scenes ... the relationship ... here with the difference between BuilderMaster and DTO.BuilderMaster objects.
Philippe Mori 29-Oct-14 23:06pm    
You can always have both if it make sense in your application. You have the simpler function that can be used when you don't already have an object and the second one when you have it.
As a Tester it is simple Option 2. This makes the creation of a mock DTO.BuilderMaster simple which in turns increases the testability of the code. Also if you need a different implementation of the DTO.BuilderMaster if you had the Buildmaster defined as an interface the you could supply any particular implmentation of the interface.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900