so toilet cleaner and programmer positions work both with the same parameters?
2010/3/8 Jamie Fraser <[email protected]> > 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 >>>> >>> >>> >> >
