No problem at all. To add to that, I would make a further distinction between an Employee (a person) and an Employment (their job). These two things are distinct, as one person can have many jobs, or indeed a single job could have N employees (think job-share).
My concern was really just about prescribing advice when it might not be appropriate :o) On Mon, Mar 8, 2010 at 12:36 PM, Processor Devil <[email protected]>wrote: > Yes, you are right it depends on the requirements. > > Maybe I was misunderstood that the class is bad at all. From my own > experience: I made a employee management system where generic data like > name, address, etc was needed, but also some more detailed data. For this > purpose I used class Employee, which I inherited in classes like Manager, > Asistant, Intern and I also used interfaces ICompanyEmployee and IContractor > to be even more specific. > Of course, when all you need are just generic data, then yes, Employee > Class is more then enough :). Sorry for the misunderstanding, issue arrived > on my side and I am really sorry for that. > > > 2010/3/8 Jamie Fraser <[email protected]> > >> What on earth is that supposed to mean? >> >> My point (which I think was quite clear) was that we have ABSOLUTELY NO >> IDEA what the system looks like or what data is required about Employees, so >> randomly prescribing that "employees is a bad class" is rather unhelpful. >> >> For example, in one of my systems, I have an Employee class which contains >> name(s), home address and contact details. Why on earth is that a bad class? >> >> >> On Mon, Mar 8, 2010 at 12:00 PM, Processor Devil < >> [email protected]> wrote: >> >>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
