First attempt at OOD: How do I extend my design?
-
Hello all! First off, sorry that it's a bit long but I have been struggling with this for a few days. I could use some help with object oriented design. My experience is primarily (nearly exclusively) as a procedural programmer, so I'm struggling with the next phase of the OO design process. I'm now working on an Employee class that will populate based upon the results of an LDAP query. So far things have been going well, but the first phase of the project has each Employee populated by the results of a FindOne() query. The value used to initialize the instance has been an employee id that is guaranteed unique so it hasn't been an issue. The user has two options to instantiate a new object. Call the constructor with the unique value, or populate the private variables and then query AD.
Employee emp = new Employee(empID);
Employee emp = new Employee();
Employee.EmpID = "12345";
Employee.ADQuery();For the next phase I'd like to be able to use FindAll() for the LDAP query and not assume that the value passed in will result in only a single return. For example, a user might want to instantiate the object by doing the following:
Employee emp = new Employee();
Employee.FirstName = "Joe";
Employee.ADQuery();My first thought was, "Fine, build an array" but after reviewing the design I'm not so sure. My design ideas have been: Simply create an array of the private instance variables that currently exist. I don't like this idea mainly because it seems that it breaks the Employee object model that I've created. I figure that if a user requests an Employee object, it should represent a single employee. Create a static method that will provide another way to instantiate the object. The static method would create multiple instances of the Employee object... essentially an array of objects. The problems I have with this is I'm not sure of a few things. I have been assuming the user would first instantiate an object and populate the instance variables with the filter criteria. If I want to allow the user to have access to all the results and not break my model, don't I need to somehow return a collection of Employee objects? Then it would seem the user would need to loop through the construct to retrieve the results. I'm not sure that requiring the looping construct to be in the implementation is the best choice. I'd like to keep the user requirements to a minimum. Also, it makes sense to me that there should be a single way of instantiating the group o
-
Hello all! First off, sorry that it's a bit long but I have been struggling with this for a few days. I could use some help with object oriented design. My experience is primarily (nearly exclusively) as a procedural programmer, so I'm struggling with the next phase of the OO design process. I'm now working on an Employee class that will populate based upon the results of an LDAP query. So far things have been going well, but the first phase of the project has each Employee populated by the results of a FindOne() query. The value used to initialize the instance has been an employee id that is guaranteed unique so it hasn't been an issue. The user has two options to instantiate a new object. Call the constructor with the unique value, or populate the private variables and then query AD.
Employee emp = new Employee(empID);
Employee emp = new Employee();
Employee.EmpID = "12345";
Employee.ADQuery();For the next phase I'd like to be able to use FindAll() for the LDAP query and not assume that the value passed in will result in only a single return. For example, a user might want to instantiate the object by doing the following:
Employee emp = new Employee();
Employee.FirstName = "Joe";
Employee.ADQuery();My first thought was, "Fine, build an array" but after reviewing the design I'm not so sure. My design ideas have been: Simply create an array of the private instance variables that currently exist. I don't like this idea mainly because it seems that it breaks the Employee object model that I've created. I figure that if a user requests an Employee object, it should represent a single employee. Create a static method that will provide another way to instantiate the object. The static method would create multiple instances of the Employee object... essentially an array of objects. The problems I have with this is I'm not sure of a few things. I have been assuming the user would first instantiate an object and populate the instance variables with the filter criteria. If I want to allow the user to have access to all the results and not break my model, don't I need to somehow return a collection of Employee objects? Then it would seem the user would need to loop through the construct to retrieve the results. I'm not sure that requiring the looping construct to be in the implementation is the best choice. I'd like to keep the user requirements to a minimum. Also, it makes sense to me that there should be a single way of instantiating the group o
After further digging, I've realized I may be combining my data layer with my domain layer. These concepts are a bit foreign to me, but I've realized there is a reason for separating these layers in order to avoid the sorts of design problems I'm encountering. I have my domain layer model of Employee and I'm trying to do the queries for LDAP in the same object. I realize now I need to separate the data access functions from the Employee class. Now I'll need to look into how the data access functions remain generic enough yet still allow you to populate the objects. Do the data access functions just exist in a "flat layer" or do they exist as objects themselves? I would think the data access methods would need to exist as extensions of the object they are to be used with. Thanks to those of you who have read through my design issues.
-
After further digging, I've realized I may be combining my data layer with my domain layer. These concepts are a bit foreign to me, but I've realized there is a reason for separating these layers in order to avoid the sorts of design problems I'm encountering. I have my domain layer model of Employee and I'm trying to do the queries for LDAP in the same object. I realize now I need to separate the data access functions from the Employee class. Now I'll need to look into how the data access functions remain generic enough yet still allow you to populate the objects. Do the data access functions just exist in a "flat layer" or do they exist as objects themselves? I would think the data access methods would need to exist as extensions of the object they are to be used with. Thanks to those of you who have read through my design issues.
Mark McArthey wrote:
Now I'll need to look into how the data access functions remain generic enough yet still allow you to populate the objects.
There are a number of different approaches, none of them are a silver bullet. You have hit at one of the stickiest problems in software design. Take a look at ORM[^] for one of the big names in this problem space.
-
Hello all! First off, sorry that it's a bit long but I have been struggling with this for a few days. I could use some help with object oriented design. My experience is primarily (nearly exclusively) as a procedural programmer, so I'm struggling with the next phase of the OO design process. I'm now working on an Employee class that will populate based upon the results of an LDAP query. So far things have been going well, but the first phase of the project has each Employee populated by the results of a FindOne() query. The value used to initialize the instance has been an employee id that is guaranteed unique so it hasn't been an issue. The user has two options to instantiate a new object. Call the constructor with the unique value, or populate the private variables and then query AD.
Employee emp = new Employee(empID);
Employee emp = new Employee();
Employee.EmpID = "12345";
Employee.ADQuery();For the next phase I'd like to be able to use FindAll() for the LDAP query and not assume that the value passed in will result in only a single return. For example, a user might want to instantiate the object by doing the following:
Employee emp = new Employee();
Employee.FirstName = "Joe";
Employee.ADQuery();My first thought was, "Fine, build an array" but after reviewing the design I'm not so sure. My design ideas have been: Simply create an array of the private instance variables that currently exist. I don't like this idea mainly because it seems that it breaks the Employee object model that I've created. I figure that if a user requests an Employee object, it should represent a single employee. Create a static method that will provide another way to instantiate the object. The static method would create multiple instances of the Employee object... essentially an array of objects. The problems I have with this is I'm not sure of a few things. I have been assuming the user would first instantiate an object and populate the instance variables with the filter criteria. If I want to allow the user to have access to all the results and not break my model, don't I need to somehow return a collection of Employee objects? Then it would seem the user would need to loop through the construct to retrieve the results. I'm not sure that requiring the looping construct to be in the implementation is the best choice. I'd like to keep the user requirements to a minimum. Also, it makes sense to me that there should be a single way of instantiating the group o
If you have your employee class built then you can do the following: public EmployeeCollection { // You can use any collection but dictionary will help you spot them easier through their id private Dictionary<string, Employee> _employees; public EmployeeCollection() { this._employees = new Dictionary<string, Employee>(); } public void Load() { // Ask the DAL class to get all the employees EmployeeCollectionMgr manager = new EmployeeCollection(); this._employees = manager.Retrieve(); // The manager can either grab the records from the database and create employee objects, add // to the collection and return the collection OR // the manager can grab all the employee ids from the database and then create an employee object and // ask the employee object to load itself. // In the first approach you need one trip to the database but you will do some of Employee's work // In the second approach you will need 1 trip per employee to the database and one to get all the ids // but Employee will do all the work // You can have many other methods here depending on the domain model at hand. } }
CodingYoshi Artificial Intelligence is no match for Human Stupidity.