Win a copy of Spring in Action (5th edition) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Is it bad practice when an Object has to be aware of another Object?  RSS feed

 
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was reading this page and came across this sentence in the accepted answer:

I don't like A directly knowing about B.



What if you can't abstract out B so that A isn't aware of it?

Suppose if I have the following Book class:



I'm aware of the fact that a book might have a list of authors, so it would be better if it was List<Author> authors, but I want to focus on a specific part of the above code sample.

Some might point out that the Book class knows about the Author object. I don't see why Author would be an interface or abstract class.

I would make Author immutable because very little about the object needs to change over time. If the author martial status changed, I could implement a method:


and return a new object reflecting that change, same goes for firstname.


Question:

Would you abstract out Author? If so, how?
 
Sheriff
Posts: 23867
50
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Emily, welcome to the Ranch!

After reading through that SO thread a couple of times it seems to me that the discussion is whether class A knows about class B. It's not so much about objects and their relationships.

And the person who made the comment which you quoted carried on by referring to the Dependency Inversion Principle, which in your example means that a Book should not care about how an Author works. It should preferably refer to an abstraction which represents what you could do with an Author.

As you say, a Book could have 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. Remember, there are other possibilities: an Author might be a person like Peter James, or it could be a corporation like Microsoft, or a university, or... so on. And if it's a person they might have (or be) a pseudonym, but universities don't, and so on and so on.

But getting back to Book, what does a Book need to know about its Author? It probably doesn't need to know any of that stuff; maybe it just needs to know that it has an Author so that it can answer the question "Who wrote you?" So there needs to be an interface which describes what a Book can do with its Author. Whether we decide to have implementing classes named CorporateAuthor or AuthorList or AnonymousAuthor, the Book class doesn't need to know.

Hope that helps...
 
Bartender
Posts: 19976
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I would make Author immutable because very little about the object needs to change over time.




Famous last words. Right up there with "It's Simple! All You Have To Do Is..."
 
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most of the time, object1 only needs to know the public interface of object2. That means you can have Corporate Authors, etc., which have the same public interface. It is a general rule of OO programming that objects only know about internal implementation of other ojects if they are created from the same class. (Or if its developers decide there are special circumstance justifying such access.) Look up informatio9n hiding.

. . . and (again) welcome to the Ranch
 
Campbell Ritchie
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 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.
An Author might also have a List<Book> showing their oeuvre. But that latter is making things too complicated, maybe.
 
Campbell Ritchie
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
I think I shall merge your other thread into this one. Note that means the two posts preceding this one will be newer than the two following it.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 
Campbell Ritchie
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I merged your stuff with the following thread. I hope that is okay by you.
 
Emily Rosemond
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As a followup to this question, I've decided to do some research and rephrase the question.

Suppose I have an Author and a Book class:



The Author class represents what you get from reading the cover of a book, nothing more, nothing less.

You could say that Book knows about Author, but to me, it doesn't make sense to abstract it out.

How would you do it?

What 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, how would you indicate the Author is also an autobiographer?

If you wanted to indicate that the Author writes different types of books, I can create an Enum called BookTypes, and Author can hold a private List that the client can load using the constructor, with different Book types

Another point, no methods exist that can be overridden. Both firstName and lastName are properties of Author and by extension, the subclasses, but suppose if the Author's marital status changed or first name, I can easily write update methods in Author. To me, it makes the most sense to keep Author immutable.

It's a good practice to follow the DIP, but what happens if following the principal is useless or might introduce unnecessary classes?

You might think I'm stubborn, going against OOP principals and trying to justify what I'm doing, but I just don't see why or how you would abstract Author when it's a simple class. Even if I introduced methods to update the first and last name, that's about all it's going to do. Different Author types don't need to exist as subclasses or implementations.
 
Emily Rosemond
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Author class with the required update methods might look like this:

 
Saloon Keeper
Posts: 5140
54
Eclipse IDE Firefox Browser Java MySQL Database VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your "update" methods are typically called "set" methods which return void. The returning of "this" is not typical but does allow chaining.
 
Campbell Ritchie
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Emily Rosemond wrote: . . . The Author class represents what you get from reading the cover of a book, nothing more, nothing less. . . . .

I am not convinced; the book cover tends to tells us at least about the author's other books.

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

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.

You might think I'm stubborn, . . . trying to justify what I'm doing

Maybe. Or maybe that you have hit an intersting question which will come up in the JavaRanch Journal and earn you a cow.

but I just don't see why or how you would abstract Author when it's a simple class. . .

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.

. . . Different Author types don't need to exist as subclasses or implementations.

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.
 
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The discussion so far is like a conversation about theoretical physics. It's called speculative design and because it's speculative and tries to address possible futures, it's wasteful. What do we know about the *actual* requirements that require such abstractions? What tensions in the surrounding code are driving the decision to add complexity to the design? If there are none, then why worry about things you don't know for sure will even happen?

Just make the code clean enough so that you can easily refactor it when whatever actual future arrives.
 
Marshal
Posts: 67163
169
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.



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.



 
Emily Rosemond
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I am not convinced; the book cover tends to tells us at least about the author's other books.


When I say front cover, I mean just that, the front cover you see on a shelf. Usually when you open the front cover or sometimes the very last page before the back cover, it might include information about other books the Author wrote.

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.



It all depends on the requirements, but here is my train of thought.

Isaac Asimov is a science fiction writer.

Robert Ludlum writes thrillers.

As you pointed out, those labels could be applied to the novel as well:

IRobot is a science fiction novel.

The Bourne Identity is a thriller novel.
 
Emily Rosemond
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.


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. I decided to encapsulate that logic in the Author class with the update methods. Set methods don't normally return anything, this is why I didn't use them. My guess is it will violate the POLA.  
 
Emily Rosemond
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Paul Clapham
Sheriff
Posts: 23867
50
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It makes sense for a Book to have an Author. It makes a lot less sense for the Book to be responsible for doing anything with that Author, except to return the Author when asked by some other code.

So if the Author has methods like getName() or accrueRoyalty() or getBooksWritten() it probably isn't necessary for the Book class to know about those methods. You could abstract them out by having Author implement some interface which doesn't have them, and then Book would have an AuthorBase... or whatever your design leads you to name the interface.

On the other hand, if the Book returns an AuthorBase when asked for its author, then the code which asked for the author might well want to accrue royalties for the author. So having abstracted that method out of the AuthorBase interface maybe wasn't such a good idea after all. Which means you have to allow your design to guide you when asking what "abstract it out" actually means.

Personally I'm not too fussed if Author has an accrueRoyalty() method and a Book has an Author but Book is not actually going to use the accrueRoyalty() method. 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.
 
Paul Clapham
Sheriff
Posts: 23867
50
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry... I just realized that you wanted a simple yes or no. Well, that was my simple yes or no.
 
Campbell Ritchie
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why shouldn't a book know whether its author is getting royalties? It might “know” about that method and never use it. Some books might be paid for by an advance full stop and some might also earn royalties.
Which all goes to show that sometimes there ain't no such thing as a simple yes or no.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.




Thanks, Bear. In the interest of transparency and full disclosure, I was paraphrasing someone smarter than me (I went ahead and added emphasis, too ):

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)


 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.


Yes, that.

To me, object-oriented programming is about good abstractions that represent ideas in your problem domain. The goal in OOAD is to discover and create those good abstractions and properly assign responsibilities to them so you can satisfy the users' current needs. I think that it's premature to dive deeply into discussions about proper abstractions and relationships if you don't have requirements that create the need to model those kinds of relationships in your system. That's kind of putting the cart way before the horse.

Try to think of it this way for a minute: What code smell(s) does the statement "Book shouldn't know about Author" address? How does a "Book knowing about Author" make it cumbersome to work with the code and add new functionality or enhance current functionality?

Don't try to model the real world in your program. That's not what OO was for. Rather, use what you and other people know about real world objects as metaphors that people can use to reason about the relationships between ideas in your problem domain and the objects that you use to represent those ideas and their relationships and responsibilities. When you have abstractions that represent the ideas in the problem domain well, the semantics of the real-world metaphors we use will usually lead to a decision on whether it's appropriate to model a relationship as "is a" or "has a" or whatever.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Emily Rosemond wrote:I wanted to keep the Author immutable


This is a good place to start. It heads off many problems that start with mutability.

... but if on some rare occasion, an attribute needed to change, I would need to create a whole new object reflecting that change.


Why? What told you this was needed? Was it a bad code smell? Or was it "intuition"? Intuition is a double-edged sword. If you have a failing test or some kind of bad smell in your code that tells you something needs to be changed, intuition can guide you to the better choice.

Daniel Kahneman gives a quote in his book, "Thinking Fast and Slow"

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


In other words, Andy Hunt's Rule#1: Always consider context.

On the other hand, when we try to use intuition to predict the future, things seldom work out the way we thought they would. I had an intuition yesterday as I was walking through the airport that I would come into a lot of money, so I bought a MegaMillions ticket from a kiosk. I woke up this morning and I still don't have 650 million dollars in the bank. I guess I'll have to stick with my backup retirement plan now.

What situation (in other words, context) exists around your decision? Don't design in a vacuum. If you're going to be a programmer, learn how to solve problems. Don't imagine problems up for yourself to solve.

My guess is it will violate the POLA.


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
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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".
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

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 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.
An Author might also have a List<Book> showing their oeuvre. But that latter is making things too complicated, maybe.



Ok, I'll bite, with the caveat that I would only really go down this path of discussion if I knew of a real need that it would satisfy, that it's not something I'm doing "just in case."

My intuition would guide me back to GRASP - General Responsibility Assignment Software Principles/Patterns and also entity-relationship analysis. Specifically, the Pure Fabrication and Join Table. Perhaps I have a BookAuthorMatchingService that keeps a record of Author-Book pairings. Those who are familiar with database design will recognize this as a many-to-many join table.

With that nugget of an idea dug up by intuition (remember what I said earlier, intuition is nothing more and nothing less than recognition), I would explore the other design decisions that would lead me to. Since I know nothing of the problem and the context around these discussions, I will say no more than that.
 
Campbell Ritchie
Marshal
Posts: 61715
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would say that a book has one or more authors, though sometimes the authors are unknown or anonymous. And that authors have books they have written. But I shall agree that at the moment we can get away without books.
 
Emily Rosemond
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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



There are no requirements, this is not an assignment for school or a task at my current job. It's just something that I thought about the other day, and I decided to write some code to see what I get. I then came across articles talking about DIP and abstracting, so I wondered, does it makes sense to abstract out Author from Book?  

When I say Book, I mean a Book you picked up off the shelf, and Authors, contains the information that you get from reading the front cover (see above).

Here is what an updated Author class might look like.



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.



This reason why I'm guessing is because a setter doesn't return anything, it sets a value. If it were to return something then it probably violates POLA, because clients didn't expect a setter to behave this way and I don't have authority to say it does violate POLA, I don't really know. 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.  

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
Greenhorn
Posts: 8
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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


Using your favorite quote:

In other words, Andy Hunt's Rule#1: Always consider context


Maybe Book and Author aren't the best example to illustrate my problem. Let me re-phrase my question.

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?

A common pattern is to abstract out the class behind an interface, but what happens if doing so is unnecessary or pointless.
 
Paul Clapham
Sheriff
Posts: 23867
50
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again, 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).

And yes, that means that you have to acquire those real-life examples. It might seem like Book and Author are a real-life example but I think you need to have a more detailed design in order to raise questions which can be answered. Because ultimately the answers come from the design's requirements.

Like for example:

Why should a sciencefictionauthor subclass exist? Why can't it be a label applied to an Author?



Okay, that's a good question. Why have a subclass instead of an attribute? Your Author class could certainly have a "Genre" attribute which you use to pigeonhole the author for whoever needs to know. But does the genre of the author cause the Author object to behave differently for different genres? We don't know without knowing the requirements. But as soon as you find your Author class has code like "If genre is sciencefiction then do this else if genre is horror then do that else if ..." then considering subclasses should arise in the designer's mind.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.


Complexity happens.

A rider on a gray horse follows soon thereafter.

Ok, a bit too dramatic but the reality is not far off. Think of the kind of unnecessary pain and suffering overly-complex programs and designs have caused all these years and the money wasted because of it. That's why I'm a big believer in YAGNI (You ain't gonna need it) and DTSTTCPW (Do the simplest thing that could possibly work). It's also why I lost all my hair. Well, a big part of the reason, at least.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?


Any situation where the principle is applied to a problem it wasn't meant to address.

What problem are you addressing by applying DIP to this kind of relationship?

DIP says that less stable parts of your program should depend on more stable parts, and not the other way around. Now, what about dependency stability is a problem between Book and Author. Is one inherently more unstable than the other? If something changes about Author, is that change likely to break any code where the Book-Author dependency comes into play? Ask the same questions going the other way, too.

I don't have any answers for you other than those questions. Again, because I don't know what exactly is the problem you're trying to solve here.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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


Yes, yes, yes.

Again, programmers should learn how to solve problems as they present themselves. The set of problems that can arise from a situation that involves hundreds of variables and moving parts is far too large for us to possibly predict and completely cover up front. We just have to do the best we can with what we know at the moment. As we learn more through testing and use of the program, we can expand our design and adapt it to handle a wider range of problems.

While you're still learning about the domain your program lives and operates in, however, focus on solving the known problems and making your program well-factored enough so it reflects your current understanding of how the program behaves as clearly and as cleanly as possible. That way, it will be easier for you and others to make changes when you discover more problems your program needs to handle.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?


Why do you worry yourself over these things? As you said, it will take time for you to gain experience. The only way to gain experience is to actually practice. Write programs. Don't embark on flights of fantasy and imagination of what you would do if this or that thing were to happen. Don't try to NOT make mistakes. On the contrary, while you're still learning, try to make as many mistakes as you can. Then understand why they are mistakes and what you can do to avoid them in the future.

You're making a mistake right now by starting with a bunch of "What if" scenarios in your head. Stop that.

Find a good problem or exercise where the DIP or whatever principle you're trying to learn might apply. Then WRITE SOME CODE. Discover what kind of problems you encounter when you make one decision or another. If the code becomes difficult to work with, try to apply the principle you're trying to learn. Come back here and ask questions, ask for advice. We're more than willing to give you some, and more.

Good luck.
 
Junilu Lacar
Sheriff
Posts: 12747
210
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.


Yes, I'm experienced but that only means I have made way more mistakes than you have.

"Experience is what allows us to recognize a mistake when we make it again."
 
Never trust an airline that limits their passengers to one carry on iguana. Put this tiny ad in your shoe:
Download Free Java APIs to Work with Office Files and PDF
htttp://www.e-iceblue.com/free-apis.html
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!