EEVblog Electronics Community Forum

Products => Computers => Programming => Topic started by: Pete66 on December 03, 2020, 10:31:55 pm

Title: Static function qestion
Post by: Pete66 on December 03, 2020, 10:31:55 pm
Here is a question.  I dont think there is a right or wrong way Im just curious to see your opinion.
The code is in C#.

I have 2 classes.
Code: [Select]
public class Author
{
public int AuthorID{ get; set; }
public string AuthorName{ get; set; }
}
public class Book
{
public int BookID{ get; set; }
public int AuthorID{ get; set; }
public string BookName{ get; set; }
}

I want to create a static method that gets a List of books by an AuthorID
Like this:
Code: [Select]
public static List<Book> GetBooks(int AuthorID)
{
List<Book> lstBooks = new List<Book>();
lstBooks = //(code to get all this authors books from DB goes here)
return lstBooks;
}

Here is the question:
Would you put this static function in the Author class or in the Book class or somewhere else?
Title: Re: Static function qestion
Post by: rs20 on December 03, 2020, 10:39:34 pm
Opinion: it should be in a Database or DatabaseReader class (or similar, haven't actually put any thought into this). If I did that, it'd also not be static (this or this.database would be the reference to the database to read from).

(Fwiw, this would help with unit testing too, because then you could pass in a fake Database or DatabaseReader for testing (unless C# has special features for unit testing static classes that I'm not aware of)).

Backup opinion: meh who cares, if just a random personal project.

Title: Re: Static function qestion
Post by: sleemanj on December 03, 2020, 11:37:15 pm
I would put it in a "Library" class (as in literary library)

Or I would make it a method of Author objects and not a static method.  Instantiate an author and ask them what books they wrote.
Title: Re: Static function qestion
Post by: Sojourner on December 06, 2020, 01:11:26 am
The approach I would take is to put it in the Book class, since the method pertains to books, and inherit the DB class.
There's no need for it to be static, unless you plan on using the method outside of the instantiated class. Such as a helper function of sorts.
Title: Re: Static function qestion
Post by: rs20 on December 06, 2020, 05:27:45 am
The approach I would take is to put it in the Book class, since the method pertains to books, and inherit the DB class.
There's no need for it to be static, unless you plan on using the method outside of the instantiated class. Such as a helper function of sorts.

I know we're just throwing opinions out here, but I have to disagree with this. If Book inherits DB, then that implies that a Book is a type of DB, just like an apple is a type of fruit. But a Book isn't a DB, it's just a Book. So having Book inherit the DB class is about as wrong is possible (or poor practice, or very likely to cause great confusion to other engineers or however you want to put it).
Title: Re: Static function qestion
Post by: Sojourner on December 06, 2020, 06:20:31 am
I agree that Book isn't a type of DB, however Book does have an 'IS-A' relationship to the DB. Book is a table, and has multiple 'HAS-A' relationships to the Book table, such as the BookName, and BookID entities within the table.

Book
------
INT BookID                 (PK)
CHAR(30) BookName

Author
--------
INT ID                        (PK)
INT AuthID                 (foreign Book.BookID)

Please correct me if my logic doesn't track.
Title: Re: Static function qestion
Post by: rs20 on December 06, 2020, 10:46:55 am
Unless I've misinterpreted, the OP is asking about the C# code. So your suggestion of having the Book class inheriting the Database class:

Code: [Select]
class Book : Database {
   ...
}

Would mean that code like this would be valid:

Code: [Select]
Book book = getBookFromSomwhere(...);
Database db = book; // valid code, but what does this mean ?!?!?!?!?

And accordingly, Book objects would have to have database-themed methods (https://docs.microsoft.com/en-us/dotnet/api/system.data.entity.database?view=entity-framework-6.2.0) like BeginTransaction and ExecuteSqlCommand. All of this makes absolutely no sense (to me at least, and I suspect any reasonably experienced software engineers), which is why I object to the idea of Book inheriting a DB class.
Title: Re: Static function qestion
Post by: Sojourner on December 06, 2020, 01:15:56 pm
You're absolutely right. My mistake.
It doesn't make sense to have the Book class inherit the DB class.
It would make more sense for the "Library" class that sleemanj suggested to inherit the DB class.

My apologies.
Title: Re: Static function qestion
Post by: rs20 on December 08, 2020, 01:27:07 am
No need to apologise, we're all learning here!
Title: Re: Static function qestion
Post by: zfzackfrost on January 07, 2021, 02:16:49 am
Opinion: it should be in a Database or DatabaseReader class (or similar, haven't actually put any thought into this). If I did that, it'd also not be static (this or this.database would be the reference to the database to read from).

(Fwiw, this would help with unit testing too, because then you could pass in a fake Database or DatabaseReader for testing (unless C# has special features for unit testing static classes that I'm not aware of)).

I agree. I dedicated collection class is the cleanest way to go about this.

Quote
Backup opinion: meh who cares, if just a random personal project.
... Well, me of course!
Title: Re: Static function qestion
Post by: radiolistener on January 10, 2021, 08:03:53 am
these classes are entities, it's better to put such method into separate class to not confuse logic code with entity definitions.