A Simple/beginner question on Generics & OOPs design

[nicholas08]

I am new to programming and trying to work on a simple console app. I am making a simple Library Management system where the user/admin can manage members and item.
Attaching the menu so it's clear to understand what I am saying.

So far I have only looked at Item and Member Management (option 1 and 2)
Few question I had:
1. In terms of the design approach I am taking.
One class to hold Member details, one for Item details - just instance vars and getters/setters
One class called LibraryManagement, which hold most of the main functionality. From here members and items will be added, edited, deleted based on user input.
One class called Menu, which only hold the Main, member and Item menu for code clarity.
====Does this seem like a reasonable design approach? ====

2. So far I have completed the Manage Member functionality. I realise that the Item Management works exactly the same way as Member management. Only diff is that a newly created item object gets added to List<Item> as opposed to member being added to List<Member> .
It seems like a waste to repeat everything and just replace List<Member> with List<Item> and Member with Item object.
I am trying to find out a way so I can use the same method to add, edit and delete details from the List and only use a generic method where the type is detected at runtime.

A snippet of some relevant code:
class LibraryManagement
{
....
Member mem;
List<Member> memberList = new List<Member>();
....
//Right now for example my method is:
public void AddMember(Member member, List<Member> listOfMembers)
{ listOfMembers.Add(member);}
//which gets called after the appropriate object is created:
public void manageMember()
{
.....
mem = new Member(id, name, address, email);
AddValues(mem, memberList);
....
}
...
}

If and how can I convert it into something generic, something like this:
addDetails<T, U>(t memberItem, U list){{ list.Add(memberItem);} //where U is a genric List and T is just any Type(in my case an Object)
and be able to call the method this way:
AddDetails(mem, memberList)
AddDetails(item, itemList)

[nukefusion]

Hello,
In terms of design approach it seems fine, although I'm not a guru on OO design or anything (theory is great up until a point, then you just need to get some work done). With my own work I always take a fairly low-level approach which I've found to work well. Some of the main things I do are:

• Try and model my solution on real world equivalents (so like in your example, I'd have a Member class to represent a Member, an Item class to represent an Item, etc, etc)
• If I have to scroll more than about a page to see my entire class, then I start thinking it's getting too big and I should try and split out the funtionality a bit. I try to keep things easy to maintain.
• Try and generalize where possible, making use of inheritance, etc. So, using your example, if Member and Item are treated in almost exactly the same way I would split the common functionaility into a base class or interface.

The third point is kind of relevant to the second thing you mention as it's probably the easiest way to eliminate code repetition. I would probably start by creating a base class (or interface, whatever is most appropriate) that has the shared functionality of both Member and Item - let's call it LibraryEntity.
Then you could write a method to do the actual management or processing of Items and Members on LibraryEntity objects instead, which you could call like so:

private void ManageEntity(LibraryEntity entity)
{
    // Do stuff to entity here (both member and library are entity objects)
    // so now we only need to write this code once
    // more code lines
    // etc etc
}
 
public void AddMember(Member member)
{
    ManageEntity(member);
    memberList.Add(member);
}
 
public void AddItem(Item item)
{
    ManageEntity(item);
    itemList.Add(item);
}
 

[nicholas08]

Thanks a lot. It took me some time to get my head around what you were saying as I am so new to this.I have been racking my brains for 2 days as I had taken a slightly different approach earlier and could not seem to disconnect from it but finally I think I have got it and I can see the benefits in working this way. The OOP theories that I have studied so far seems so much practical now :) Thanks again.