I don't like A directly knowing about B.
I would make Author immutable because very little about the object needs to change over time.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
I think I would prefer the book to have a List of authors. If you have a book like Gamma Helm Johnson and Vlissides, with four authors, which author would hold the List? And I wouldn't want such a List as a static field of Author, so it probably belongs to the book.Paul Clapham wrote:. . . more than one Author. A design could implement that by having Book have a List of Authors, or you could force Author to take care of the list possibility. . . .
I am not convinced; the book cover tends to tells us at least about the author's other books.Emily Rosemond wrote: . . . The Author class represents what you get from reading the cover of a book, nothing more, nothing less. . . . .
Do you think of people as authors of a particular genre? Dorthy L Sayers wrote mostly detective stories, but she alsoWhat happens if one author writes different types of books, for example, a science-fiction writer might also write autobiographies of celebrities. If Author were abstract and had a ScienceFictionAuthor subclass . . .
Maybe. Or maybe that you have hit an intersting question which will come up in the JavaRanch Journal and earn you a cow.You might think I'm stubborn, . . . trying to justify what I'm doing
You don't make an abstraction from a class. A class IS‑AN abstraction of a real‑life object already. Your class encapsulates a name, and it doesn't say what that name is. That makes it an abstraction.but I just don't see why or how you would abstract Author when it's a simple class. . .
That sounds the same as I said a few lines back. But without some sort of information about books, or even genres, I am finding it hard to distinguish yoiur Author class from a simple Name class.. . . Different Author types don't need to exist as subclasses or implementations.
Junilu Lacar wrote:Just make the code clean enough so that you can easily refactor it when whatever actual future arrives.
Junilu Lacar wrote:Just make the code clean enough so that you can easily refactor it when whatever actual future arrives.
Junilu Lacar wrote:Just make the code clean enough so that you can easily refactor it when whatever actual future arrives.
Junilu Lacar wrote:Just make the code clean enough so that you can easily refactor it when whatever actual future arrives.
I am not convinced; the book cover tends to tells us at least about the author's other books.
Do you think of people as authors of a particular genre? Dorthy L Sayers wrote mostly detective stories, but she also wrote translated Dante's Divine Comedy.
C S Lewis wrote mostly theology, but also wrote 3½ fantasy/SF books. (the Ransom trilogy and Screwtape, which I will put down as half a book because it is hal fantasy and half theology). Or you can include Narnia and make that 10½.
I am not convinced that there is such a person as an SF author, or a biographical author. Maybe the genre belongs to the book rather than the author.
Carey Brown wrote:Your "update" methods are typically called "set" methods which return void. The returning of "this" is not typical but does allow chaining.
Bear Bibeault wrote:Quoted 4 times for emphasis!
Junilu Lacar wrote:Just make the code clean enough so that you can easily refactor it when whatever actual future arrives.
Don’t write code that guesses the future, arrange code so that you can adapt to the future when it arrives.
—Sandi Metz, on Twitter (https://twitter.com/sandimetz/status/441241600077725697)
Paul Clapham wrote:I'd consider statements like "Book shouldn't know about Author" to be pontificating -- in other words I'm more practical than theoretical these days.
Emily Rosemond wrote:I wanted to keep the Author immutable
... but if on some rare occasion, an attribute needed to change, I would need to create a whole new object reflecting that change.
The situation has provided a cue; this cue has given the expert access to information stored in memory, and the information provides the answer. Intuition is nothing more and nothing less than recognition. —Herbert Simon
My guess is it will violate the POLA.
Emily Rosemond wrote:Given the requirements, my question still remains, and it's a simple yes or no. Author is an attribute of the Book class, does it make sense to abstract it out?
Campbell Ritchie wrote:
I think I would prefer the book to have a List of authors. If you have a book like Gamma Helm Johnson and Vlissides, with four authors, which author would hold the List? And I wouldn't want such a List as a static field of Author, so it probably belongs to the book.Paul Clapham wrote:. . . more than one Author. A design could implement that by having Book have a List of Authors, or you could force Author to take care of the list possibility. . . .
An Author might also have a List<Book> showing their oeuvre. But that latter is making things too complicated, maybe.
Junilu Lacar wrote:
Emily Rosemond wrote:Given the requirements, my question still remains, and it's a simple yes or no. Author is an attribute of the Book class, does it make sense to abstract it out?
Maybe I missed it but what are the actual requirements? At face value and not knowing anything about the context, my answer would be a quick "No".
The key word there is "guess." Don't guess at problems; address them when they come up. Again, just make your code clean enough so you can easily refactor it to address any problems that come up.
Junilu Lacar wrote:Maybe I missed it but what are the actual requirements? At face value and not knowing anything about the context, my answer would be a quick "No".
In other words, Andy Hunt's Rule#1: Always consider context
Why should a sciencefictionauthor subclass exist? Why can't it be a label applied to an Author?
Emily Rosemond wrote:A common pattern is to abstract out the class behind an interface, but what happens if doing so is unnecessary or pointless.
Emily Rosemond wrote:When a class is an attribute of another class, does it always make sense to follow DIP? Are there situations where following DIP will introduce more problems than it solves?
Paul Clapham wrote:... these days I find it hard to learn things by discussing theories. I find it much more useful to look at actual real-life examples (or reasonable approximations) and understand how they illustrate the theories (or how they conflict with them).
Emily Rosemond wrote:This code isn't meant for a program sitting in a publishing company or to interact with a sophisticated database. It's to illustrate my problem, Are there situations where it doesn't makes sense to follow DIP? Book and Author were the only example I could come up with. Why should a specific type of Author exist? Why should a sciencefictionauthor subclass exist? Why can't it be a label applied to an Author?
Emily Rosemond wrote:You might be able to, because you have years of experience, so you'll be able to look at the code and know, for beginners, it will take time.