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 >>>>> >>>> >>>> >>> >> >
