Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 397
  • Last Modified:

C# Interface vs. Abstract best practice question

I'm really just trying to make sure I'm not misunderstanding interfaces and how they are implemented.  Here is some code to show what I am doing:
This is my interface:
namespace InterfaceTest
{
    public interface IComment
    {
        Guid ID { get; }
        string Comment { get; set; }
        string EnteredBy { get; set; }
        DateTime UtcDateTime { get; }

        bool Insert();
    }
}

Open in new window


This is my implementation of the interface:
namespace InterfaceTest
{
    public class CustomerComment : IComment
    {
        public string Comment { get; set; }
        public string EnteredBy { get; set; }
        public Guid ID { get; private set; }
        public Guid CustomerID { get; private set; }
        public DateTime UtcDateTime { get; private set; }
        public CustomerComment(string comment, Guid customerID, string enteredBy)
        {
            this.Comment = comment;
            this.CustomerID = customerID;
            this.EnteredBy = enteredBy;
        }

        public static List<CustomerComment> GetComments()
        {
            List<CustomerComment> result = new List<CustomerComment>();

            result.Add(new CustomerComment("comment",Guid.Empty,"username"));

            return result;
        }

        public bool Insert()
        {
            bool result = false;

            return result;
        }
    }
}

Open in new window


My questions pertain to the CustomerID Property and Static GetComments method I added.  Should this not be done since it goes beyond the interface definition?  And if it shouldn't be done then what is the way I should do it?  For instance I would be Implementing another comment for say UserComment : IComment where there wouldn't be a CustomerID but instead a UserID.
0
jetskij16
Asked:
jetskij16
  • 2
  • 2
1 Solution
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
There's nothing technically wrong with what you've done.  We can't answer, however, whether it's the best approach for your situation.  An immediate question I would ask is do those changes belong in the IComment() interface?

A class can certainly have it's own properties and methods, as well as implement multiple interfaces and inherit from another class at the same time.
0
 
jetskij16Author Commented:
My original thought was that for each of the comments Customer, User, Order that I would add the CustomerID,UserID,OrderID to the implementation of the Icomment instead of in the interface.  Does that sound like a best practice or common practice?

And with regards to the static List<> method that was just an attempt at providing a way to call all the comments for say a customer.  Is there a better way you would suggest doing that portion?

Thanks for the help.
0
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
"... with regards to the static List<> method that was just an attempt at providing a way to call all the comments for say a customer."

So you want to return all comments given a particular CustomerID?  Your class is of type "CustomerComment" which implies that it is ONE customer comment.  WHERE are you storing all the other instances of CustomerComment()?  You'd need a static List<> to hold all of them, or a database that stores the information from which you can create instances to return.
0
 
jetskij16Author Commented:
To make it easier i have pulled that functionality of getting a list of CustomerComment into the Customer Class.  Thank you for your help and I have marked the first answer as accepted.

CustomerComment is meant to be the class name where I might have a list of them I generally call CustomerComments for the name.  These get stored in a DB.

Thank you again.
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now