Timeline for Breadth First Search not SOLID enough v2.0
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 9, 2014 at 0:49 | comment | added | xaisoft | Great. It makes sense now. Thanks for the link and detailed answer. | |
| Oct 9, 2014 at 0:48 | vote | accept | xaisoft | ||
| Oct 8, 2014 at 16:29 | comment | added | Jesse C. Slicer | @xaisoft for me, I try to start at that point and only move to mutable state when the design calls for it. It's an adherence to the Principle of Least Privilege: en.wikipedia.org/wiki/Principle_of_least_privilege | |
| Oct 8, 2014 at 15:46 | comment | added | xaisoft | OK, great. Thanks for taking the time to answer all of these. One last question: How do I know when to make a class immutable or not, for example? This also applies to doing other things such as choosing between collections? | |
| Oct 8, 2014 at 15:01 | comment | added | Jesse C. Slicer |
@xaisoft 1b) language-provided immutability is making all your class state locked in by readonly and having only property getters. It means, after construction, nothing about the instance changes.
|
|
| Oct 8, 2014 at 2:10 | history | edited | Jesse C. Slicer | CC BY-SA 3.0 |
added `TextWriter` example.
|
| Oct 8, 2014 at 2:08 | comment | added | Jesse C. Slicer | @xaisoft 5) I'll add a section at the bottom of the answer to show this. | |
| Oct 8, 2014 at 2:08 | comment | added | Jesse C. Slicer | @xaisoft 4) Yes. If you figure there are going to be multiple path-finding/printing objects, then revisit the design and go with interfaces. | |
| Oct 8, 2014 at 2:06 | comment | added | Jesse C. Slicer |
@xaisoft 3) Nope. A class with no state is a static class that shouldn't have an interface. However, you may look at your design if you find yourself in that situation and see if there are common parameters to the methods that could be class state passed in the constructor instead.
|
|
| Oct 8, 2014 at 2:05 | comment | added | Jesse C. Slicer |
@xaisoft 2) sealed is a keyword which makes your classes non-inheritable. You should do that if you don't want anyone to subclass your classes. It also guarantees that any immutable classes are truly immutable and no other subclass breaks that contract.
|
|
| Oct 8, 2014 at 2:04 | comment | added | Jesse C. Slicer |
@xaisoft 1) yes. by developing to interfaces (INode vs. Node in the Edge class, for instance) - you decouple your interface from your implementation. Loose coupling is a hallmark of good OO design. Plug, it allows you to unit test your components by mocking out the dependent interfaces.
|
|
| Oct 8, 2014 at 1:24 | comment | added | xaisoft |
Thanks for this so far. It is really great. I have a few questions: 1) Can you elaborate on developing to interfaces and language-provided immutability?, 2) What benefit does making the concrete classes sealed?, 3) If there is no state, does it make sense to have an interface?, 4) Also, by removing the interfaces, if I want to implement another way of path finding or path printing, don't I have to create new classes anyways?, 5) I am a bit confused on passing in a TextWriter to PathPrinter, can you possibly provide an example of how that works?
|
|
| Oct 7, 2014 at 22:08 | history | edited | Jesse C. Slicer | CC BY-SA 3.0 |
added tons of stuff. SRP.
|
| Oct 7, 2014 at 21:54 | comment | added | Jesse C. Slicer |
@xaisoft I'm just about ready. I chose ICollection as the implementation didn't need any functionality that's from any more specific interface. Rule of thumb is to code to the least-general interface you want to support. I'm working backward here, so I made the judgment call.
|
|
| Oct 7, 2014 at 21:49 | comment | added | xaisoft | Great! I can't wait to see it. Would you also enlighten me as why you chose some data structures, such as ICollection instead of IList for example as well? | |
| Oct 7, 2014 at 21:14 | history | answered | Jesse C. Slicer | CC BY-SA 3.0 |