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

up vote
2
down vote

favorite

I was reading this page and came across this sentence in the accepted answer:

I don't like A directly knowing about B. But that's a DIP thing
not a POJO thing.

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

Suppose if I have the following Book class:

public final class Book 

 private final Author author;

 // constructor and methods left out :D. 
 


public final Author 

 private final String firstName;
 private final String lastName;

 // constructor and methods left out :D.

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.

Question:

Would you abstract out Author? If so, how?

asked 3 hours ago

BasementJoe

1597

add a commentÂ |Â

up vote
2
down vote

favorite

I was reading this page and came across this sentence in the accepted answer:

I don't like A directly knowing about B. But that's a DIP thing
not a POJO thing.

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

Suppose if I have the following Book class:

public final class Book 

 private final Author author;

 // constructor and methods left out :D. 
 


public final Author 

 private final String firstName;
 private final String lastName;

 // constructor and methods left out :D.

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.

Question:

Would you abstract out Author? If so, how?

asked 3 hours ago

BasementJoe

1597

add a commentÂ |Â

up vote
2
down vote

favorite

I was reading this page and came across this sentence in the accepted answer:

I don't like A directly knowing about B. But that's a DIP thing
not a POJO thing.

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

Suppose if I have the following Book class:

public final class Book 

 private final Author author;

 // constructor and methods left out :D. 
 


public final Author 

 private final String firstName;
 private final String lastName;

 // constructor and methods left out :D.

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.

Question:

Would you abstract out Author? If so, how?

asked 3 hours ago

BasementJoe

1597

I was reading this page and came across this sentence in the accepted answer:

I don't like A directly knowing about B. But that's a DIP thing
not a POJO thing.

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

Suppose if I have the following Book class:

public final class Book 

 private final Author author;

 // constructor and methods left out :D. 
 


public final Author 

 private final String firstName;
 private final String lastName;

 // constructor and methods left out :D.

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.

Question:

Would you abstract out Author? If so, how?

java object-oriented class-design abstraction

asked 3 hours ago

BasementJoe

1597

asked 3 hours ago

BasementJoe

1597

asked 3 hours ago

BasementJoe

1597

asked 3 hours ago

BasementJoe

1597

asked 3 hours ago

BasementJoe

1597

add a commentÂ |Â

2 Answers
2

active

oldest

votes

up vote
2
down vote

accepted

The way that in your example the Book class depends on Author, it's quite plausible that Author depends on Country, Town and Language (describing home town and native language), and so on.

For the productive use of the program, you'll probably need Books with Authors having all these properties. So, there's nothing really wrong about that approach.

But if you want to unit-test some functionality about Books, you'll appreciate not having to construct full-fledged Authors with their Country, Town and Language instances (and their dependencies and so on). Instead you'll want to use mockups with just enough functionality to support the Book class.

To make that easy, define as an interface the API that an Author offers to other classes (hopefully Book and e.g. PublishingCompany need similar methods from Author, otherwise you should create multiple interfaces). Then for testing purposes, you (or your preferred mocking framework) can supply Author-like objects that are sufficient for Book, but don't need all the other classes.

Of course, there are situations where this is just over-engineering, e.g. if Author really is nothing more than a holder for first and last name.

answered 3 hours ago

Ralf Kleberhoff

3,296414

add a commentÂ |Â

up vote
4
down vote

Whether we want to use an abstraction(interfaces and abstract classes) depends on whether we want the following advantages :

We want to be able to comfortably switch between different implementations of Author like ScientificJournalAuthor or FictionAuthor or a AutoBiographyAuthor. If all these different authors follow the contract of the interface Author, you will be able to use them interchangeably in certain scenarios, reaping the benefits of code reuse.

By thinking in terms of an Abstraction, you will be able to narrow down on the minimal amount of functionality you need from an Author for the Book class. This knowledge will help you keep your implementation of Book decoupled from implementations of Author.

Warning : Make sure you don't spawn too many abstractions as this can reduce code readability and make you spend time thinking about things that aren't necessary and provide little code reuse.

answered 1 hour ago

Harsh Verma

411

New contributor

1

This answer provides a good example of why in this case, the more general reasoning it that this approach make the software more flexible with regard to enhancement and is closely related to the Open Closed principle en.wikipedia.org/wiki/Open%E2%80%93closed_principle
â€“Â Martin Spamer
1 hour ago

The problem is, I don't see why different subclasses of Author need to exist. The types you provide in your first point could just as easily be stored in a List collection called genres, to indicate that one author might write multiple types of books.
â€“Â BasementJoe
8 mins ago

add a commentÂ |Â

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "131"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f380001%2fis-it-bad-practice-when-an-object-has-to-be-aware-of-another-object%23new-answer', 'question_page');

);

Post as a guest

Name

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

up vote
2
down vote

accepted

For the productive use of the program, you'll probably need Books with Authors having all these properties. So, there's nothing really wrong about that approach.

Of course, there are situations where this is just over-engineering, e.g. if Author really is nothing more than a holder for first and last name.

answered 3 hours ago

Ralf Kleberhoff

3,296414

add a commentÂ |Â

up vote
2
down vote

accepted

For the productive use of the program, you'll probably need Books with Authors having all these properties. So, there's nothing really wrong about that approach.

Of course, there are situations where this is just over-engineering, e.g. if Author really is nothing more than a holder for first and last name.

answered 3 hours ago

Ralf Kleberhoff

3,296414

add a commentÂ |Â

up vote
2
down vote

accepted

For the productive use of the program, you'll probably need Books with Authors having all these properties. So, there's nothing really wrong about that approach.

Of course, there are situations where this is just over-engineering, e.g. if Author really is nothing more than a holder for first and last name.

answered 3 hours ago

Ralf Kleberhoff

3,296414

For the productive use of the program, you'll probably need Books with Authors having all these properties. So, there's nothing really wrong about that approach.

Of course, there are situations where this is just over-engineering, e.g. if Author really is nothing more than a holder for first and last name.

answered 3 hours ago

Ralf Kleberhoff

3,296414

answered 3 hours ago

Ralf Kleberhoff

3,296414

answered 3 hours ago

Ralf Kleberhoff

3,296414

answered 3 hours ago

Ralf Kleberhoff

3,296414

add a commentÂ |Â

up vote
4
down vote

Whether we want to use an abstraction(interfaces and abstract classes) depends on whether we want the following advantages :

We want to be able to comfortably switch between different implementations of Author like ScientificJournalAuthor or FictionAuthor or a AutoBiographyAuthor. If all these different authors follow the contract of the interface Author, you will be able to use them interchangeably in certain scenarios, reaping the benefits of code reuse.

By thinking in terms of an Abstraction, you will be able to narrow down on the minimal amount of functionality you need from an Author for the Book class. This knowledge will help you keep your implementation of Book decoupled from implementations of Author.

Warning : Make sure you don't spawn too many abstractions as this can reduce code readability and make you spend time thinking about things that aren't necessary and provide little code reuse.

answered 1 hour ago

Harsh Verma

411

New contributor

1

This answer provides a good example of why in this case, the more general reasoning it that this approach make the software more flexible with regard to enhancement and is closely related to the Open Closed principle en.wikipedia.org/wiki/Open%E2%80%93closed_principle
â€“Â Martin Spamer
1 hour ago

The problem is, I don't see why different subclasses of Author need to exist. The types you provide in your first point could just as easily be stored in a List collection called genres, to indicate that one author might write multiple types of books.
â€“Â BasementJoe
8 mins ago

add a commentÂ |Â

up vote
4
down vote

Whether we want to use an abstraction(interfaces and abstract classes) depends on whether we want the following advantages :

We want to be able to comfortably switch between different implementations of Author like ScientificJournalAuthor or FictionAuthor or a AutoBiographyAuthor. If all these different authors follow the contract of the interface Author, you will be able to use them interchangeably in certain scenarios, reaping the benefits of code reuse.

By thinking in terms of an Abstraction, you will be able to narrow down on the minimal amount of functionality you need from an Author for the Book class. This knowledge will help you keep your implementation of Book decoupled from implementations of Author.

Warning : Make sure you don't spawn too many abstractions as this can reduce code readability and make you spend time thinking about things that aren't necessary and provide little code reuse.

answered 1 hour ago

Harsh Verma

411

New contributor

1

This answer provides a good example of why in this case, the more general reasoning it that this approach make the software more flexible with regard to enhancement and is closely related to the Open Closed principle en.wikipedia.org/wiki/Open%E2%80%93closed_principle
â€“Â Martin Spamer
1 hour ago

The problem is, I don't see why different subclasses of Author need to exist. The types you provide in your first point could just as easily be stored in a List collection called genres, to indicate that one author might write multiple types of books.
â€“Â BasementJoe
8 mins ago

add a commentÂ |Â

up vote
4
down vote

Whether we want to use an abstraction(interfaces and abstract classes) depends on whether we want the following advantages :

We want to be able to comfortably switch between different implementations of Author like ScientificJournalAuthor or FictionAuthor or a AutoBiographyAuthor. If all these different authors follow the contract of the interface Author, you will be able to use them interchangeably in certain scenarios, reaping the benefits of code reuse.

By thinking in terms of an Abstraction, you will be able to narrow down on the minimal amount of functionality you need from an Author for the Book class. This knowledge will help you keep your implementation of Book decoupled from implementations of Author.

Warning : Make sure you don't spawn too many abstractions as this can reduce code readability and make you spend time thinking about things that aren't necessary and provide little code reuse.

answered 1 hour ago

Harsh Verma

411

New contributor

Whether we want to use an abstraction(interfaces and abstract classes) depends on whether we want the following advantages :

We want to be able to comfortably switch between different implementations of Author like ScientificJournalAuthor or FictionAuthor or a AutoBiographyAuthor. If all these different authors follow the contract of the interface Author, you will be able to use them interchangeably in certain scenarios, reaping the benefits of code reuse.

By thinking in terms of an Abstraction, you will be able to narrow down on the minimal amount of functionality you need from an Author for the Book class. This knowledge will help you keep your implementation of Book decoupled from implementations of Author.

Warning : Make sure you don't spawn too many abstractions as this can reduce code readability and make you spend time thinking about things that aren't necessary and provide little code reuse.

answered 1 hour ago

Harsh Verma

411

New contributor

answered 1 hour ago

Harsh Verma

411

New contributor

answered 1 hour ago

Harsh Verma

411

answered 1 hour ago

Harsh Verma

411

New contributor

Harsh Verma is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

1

This answer provides a good example of why in this case, the more general reasoning it that this approach make the software more flexible with regard to enhancement and is closely related to the Open Closed principle en.wikipedia.org/wiki/Open%E2%80%93closed_principle
â€“Â Martin Spamer
1 hour ago

The problem is, I don't see why different subclasses of Author need to exist. The types you provide in your first point could just as easily be stored in a List collection called genres, to indicate that one author might write multiple types of books.
â€“Â BasementJoe
8 mins ago

add a commentÂ |Â

1

This answer provides a good example of why in this case, the more general reasoning it that this approach make the software more flexible with regard to enhancement and is closely related to the Open Closed principle en.wikipedia.org/wiki/Open%E2%80%93closed_principle
â€“Â Martin Spamer
1 hour ago

The problem is, I don't see why different subclasses of Author need to exist. The types you provide in your first point could just as easily be stored in a List collection called genres, to indicate that one author might write multiple types of books.
â€“Â BasementJoe
8 mins ago

This answer provides a good example of why in this case, the more general reasoning it that this approach make the software more flexible with regard to enhancement and is closely related to the Open Closed principle en.wikipedia.org/wiki/Open%E2%80%93closed_principle
â€“Â Martin Spamer
1 hour ago

The problem is, I don't see why different subclasses of Author need to exist. The types you provide in your first point could just as easily be stored in a List collection called genres, to indicate that one author might write multiple types of books.
â€“Â BasementJoe
8 mins ago

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky