Timeline for SOLID vs. Avoiding Premature Abstraction
Current License: CC BY-SA 2.5
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 6, 2011 at 23:38 | comment | added | dsimcha |
IMHO the best level of abstraction to think at is the level that you expect consumers of the object to use. Say you have an object called Queryer that optimizes database queries, queries the RDBMS and parses the results into objects to return. If there's only one way to do this in your app and Queryer is hermetically sealed and encapsulates this one way, then it only does one thing. If there are multiple ways to do this and someone might care about the details of one part of it, then it does multiple things and you might want to split it up.
|
|
| Apr 6, 2011 at 19:14 | comment | added | jprete | There is definitely a spectrum of conceptual levels, but we can pick a point on it: the size of a "class that does one thing" should be such that you can almost immediately understand the implementation. I.e. the implementation details fit in your head. If it gets bigger, then you can't understand the whole class at once. If it's smaller, then you are abstracting too far. But as you said in another comment, there's a lot of judgment and experience involved. | |
| Apr 6, 2011 at 18:55 | comment | added | Mason Wheeler | "Does more than one thing" can be difficult to define, depending on what level of abstraction you're working at. It could be argued that any method with two or more lines of code is doing more than one thing. At the opposite end of the spectrum, something complex like a scripting engine is going to need a whole lot of methods that all do individual "things" that are not directly related to each other, but each comprise an important part of the "meta-thing" which is getting your scripts to run properly, and there's only so much breaking apart that can be done without breaking the script engine. | |
| Apr 6, 2011 at 18:44 | history | answered | jprete | CC BY-SA 2.5 |