Or How to craft objects that work There are some traits that I use to check my software against. Probably the main one is . It says that your abstraction is good only if there are more than one implementation. In other words, it poses that abstractions should be, well, abstract. Reused Abstraction Principle Mark Seemann has a nice about solution space approaches that can lead to better abstractions. post But OOP starts much earlier than you start writing code. It starts when you talk to your domain expert. Get to know your problem Plato, in his dialogue, that our design should be domain-driven and should start in problem space. He describes this principle as follows: Phaedrus says [The principle of] perceiving and bringing together in one idea the scattered particulars, that one may make clear by definition the particular thing which he wishes to explain; just as now, in speaking of Love , . Certainly by this means the . [I think Eros was meant here] we said what he is and defined it, whether well or ill discourse acquired clearness and consistency This resonates with to decomposing system into modules. Parnas’s approach Decompose your problem space When I’ve figured out my domain, I set off to decomposition. the main trait that decomposition must possess: Plato describes [The principle] of dividing things again by classes, where the natural joints are, and not trying to break any part, after the manner of a bad carver. Procedural programming proved to be a poor guide to good decomposition. Neither data nor procedures suit for that purpose. But what does? Well, since we’re doing OOP here, no surprise that the answer is behavior. The natural joints mentioned above are the objects’ boundaries.By the way, the same principle applies to . identifying service boundaries Practical consequences The first one is that the elements resulted from right decomposition are composable, while the number of abstractions is relatively low. It is not a scientific statement, more like empirical. Look at chemistry: less than 130 elements in Periodic table. : 13 axioms. Algebra: 10 numbers and a bunch of operations. Reused Abstraction Principle is naturally satisfied. Euclidean geometry Composability implies that the entities share the same interface. It means that there are a lot of replaceable things around us. I don’t care what bus takes me to the office — I only care about its number. I don’t care what jeans I wear — the size is probably the only criteria. Or what chair, table or pen I use. Metaphors to guide you through objects finding in his book describes some useful metaphors that characterize the right decomposition. They all are applied to problem space, i.e., to domain. David West Object Thinking The first one is Lego. There are a lot of parts in Lego, but there are way fewer of parts. And all of the parts are highly composable.The second one is a person metaphor. I used it before I read the book, so it’s the one most natural for me. Even more specific, I conjure not just a person, but an adult person, who makes decisions, tells right from wrong, and decides how to do anything he or she should do.The third one is theater. Every actor knows how to play its role, and every actor is fine with possible replacement of some of their colleagues.The metaphor of object collaboration that I liked is that of an ants. Scientifically proven (there is even a link in a book!) that there is absolutely no orchestration of ants. They all are equal. So as objects should. types Example I tried to apply these principles in designing library.I basically need two things: create datetime object out of arbitrary format, and output them in arbitrary format. Hence two interfaces — and . Besides I need an interface to work with intervals. Three directories correspond to these interfaces.I also need a possibility to specify datetimes relatively. So I have a timeline directory with three classes: Past, Now and Future.And finally I want a comparison capability, I expressed it with two classes: and . It is possible to implement any comparison with them. DateTime ISO8601DateTime FormattedDateTime Min Max Here is an example of what can be expressed with this library: // outputs truevar_dump( (new Max( new Future( new Past( new FromMilliseconds( (new ToMilliseconds( new FromISO8601('2017-08-18T15:08:13+04:00') )) ->value() ), new ISO8601Interval('P1Y2M21DT24H56M26S') ), new ISO8601Interval('PT23H') ), new Now() )) ->equalsTo(new Now())); Objects are composable, and there are way more classes than interfaces. So my goal is achieved. This library is just an experiment for now, it lacks some functionality and already has some issues (I don’t like copy-paste in methods), but the whole decomposition seems to be fine. equalsTo() Summing it up So start with problem space — your domain. Use behavior as a decomposition criteria. Remember the metaphors. Let the composability be your goal.
