btw, could it happen that you also got an e-mail from [email protected] that your e-mail is blacklisted? I get this message everytime I reply to this topic :D.
2010/3/8 Jamie Fraser <[email protected]> > 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
