Yes! I've been getting quite a few of them this morning :( CEREBRUUUUUUSSSSS!!! ;-)
On Mon, Mar 8, 2010 at 12:43 PM, Processor Devil <[email protected]>wrote: > 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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
