Static function qestion

[Pete66]

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?

[rs20]

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.

[sleemanj]

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.

[Sojourner]

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.

[rs20]

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

[Sojourner]

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.

[rs20]

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

[Sojourner]

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.

[rs20]

No need to apologise, we're all learning here!

[zfzackfrost]

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.

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

... Well, me of course!

[radiolistener]

these classes are entities, it's better to put such method into separate class to not confuse logic code with entity definitions.