Employee is a PERFECTLY good class - you are assuming that working hours and policy are relevant?
Randomly using an interface when there is no apparent need for it (you are assuming things you shouldn't) is a recipe for an overly complex system. Remember YAGNI. On Mon, Mar 8, 2010 at 11:27 AM, Processor Devil <[email protected]>wrote: > Employee is not a good class at all... > Employees have different functions, different working hours, different > policy, etc. > > I would either make a virtual class Employee which would have to be derived > or IEmployee interface, both works great and application can be easily > enhanced and maintained. Code is more reusable, too. > > "If design is wrong, don't think that the final app will be better" > > 2010/3/8 Jamie Fraser <[email protected]> > > Personally I would have >> >> POCO class - i.e. Employee, which contains properties and not a lot more. >> >> Service/Factory/Repository (as required) - EmployeeRepository, >> EmployeeFactory etc. This will hydrate, add, delete your Employee classes. >> >> I wouldn't put your "add employee" logic into your Employee class, because >> it doesn't really belong there. >> >> >> On Sun, Mar 7, 2010 at 11:54 PM, raringsunny <[email protected]>wrote: >> >>> Thanks for a response Vipin. >>> >>> On Mar 7, 2:00 pm, crazy <[email protected]> wrote: >>> > I think, you can store all the property varibales in a seperate class >>> and >>> > serialize that class and u can create a generic list of this class for >>> > moving data from one layer to another layer and also u can inherit >>> this >>> > class for other scenarios like EmployeeSalary or EmployeeLeave etc... >>> > >>> > I dont know is there anything wrong in this Logic.. >>> > >>> > Thanks >>> > Vipin! >>> > >>> > >>> > >>> > >>> > >>> > On Sun, Mar 7, 2010 at 9:43 AM, raringsunny <[email protected]> >>> wrote: >>> > > Thanks for responding Brandon. >>> > >>> > > One advantage I see in having a separate class is that if I serialize >>> > > my properties class into XML, I can then send that XML object to the >>> > > database procedure. Using OpenXML, it would be easier to store the >>> > > information in the database. >>> > >>> > > I am seeking more ideas on what is the best way to do it? Is there >>> any >>> > > downside If I serialize a class which also contains method >>> > > definitions? >>> > >>> > > On Mar 7, 12:27 am, Brandon Betances <[email protected]> wrote: >>> > > > tl;dr: I wouldn't do it. >>> > >>> > > > Well I think your confusing yourself. You* *say you made a class >>> called >>> > > > Employees, and then ask if you should make 2 classes; what I *think >>> *your >>> > > > getting at is a making a partial class, and containing methods >>> inside its >>> > > > own class *file*. In that case, if thats how you want to do it, >>> there is >>> > > no >>> > > > effect on the class when its compiled, that I know of. Really, >>> there's no >>> > > > sense in making a completely separate class to perform work on the >>> > > > properties of another class. Then you'd have a problem with >>> instances of >>> > > the >>> > > > class, when you could just do the work in the one single *current >>> > > *instance >>> > > > of the class. >>> > >>> > -- >>> > "People who never make mistakes, never do anything." >>> > >>> > dEv >>> >> >> >
