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