Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Forgive the title, it’s simpler than it sounds.
I’ve got a class, StickerBook. It contains some stickers, List<Sticker>.
When it’s time to see if there any stickers waiting to be added, should StickerBook.CheckForNewStickers() handle the logic of looking for them and then adding them, or should a new class, NewStickerChecker check for and then add them to the StickerBook?
A pretty basic concept I know, I just can’t wrap my head around it.
Pretty sure there’s no right or wrong answer to this. Either way you seem to be encapsulating the logic rather than making the internals of the class (List) open to all which is generally a good thing.
Putting logic into a separate service class (and having this class implement an interface) could make unit testing easier if you then pass this interface to other pieces of code as a dependency. I think it’s conceptually easier to mock up a service class and pass around the actual simple entities during testing rather than mock up entities with complex logic on them.