How Atoms differ from Elegant Objects

Elegant Objects

Atoms derived very much from Elegant Objects. However, the purpose of the OO-atom project is a bit different. While Elegant Objects raise problems of today's OOP design and proposes practical recommendations for solving them, OO-atom looks at the same problems from Java bytecode perspective. How Java code, written in "elegant" object-oriented way, may be proved for correctness? How can it be optimized? How to write "elegant" objects and at the same time embrace and use existing solutions in Java ecosystem?

Also, in particular, there are some significant conceptual differences between Elegant Objects and OO-atom which worth to be mentioned:

First, according to "Elegant Objects", classes are supposed to be either final or abstract ("Elegant Objects" vol. 1, section 4.3). This restriction comes from intention to eliminate implementation inheritance as a kind. While the purpose is fine per-se, restriction to make non-final classes introduces two problems with supplementary constructors:

• Because class can't be non-final, the only suitable place to put in supplementary constructor is the class itself. This leads to uncontrollably growing number of constructors in one class in cases, when there are plenty of possible ways to instantiate an object.
• Client code may sometimes introduce new way to instantiate an object. But since the class of the object may be only final, there is no way to declare new constructors. This usually leads to code duplication on client side (TODO: example).

Alternate way out of this may be to give client code an ability to define new ways of creating an object. Define new constructors. With this idea in mind, Atom aliases were introduced. They allow to distribute and maintain constructors in more flexible way and at the same time keep implementation inheritance not possible.

Second, OO-atom provides an alternate vision on solving mistake, related to equals/hashCode presence in Java's java.lang.Object. Instead of proposing the alternate ways of designing code of these methods, OO-atom proposes more cardinal solution. Main idea is that developer must not ever have a way to define or override objects equality based on field's state. Instead, its the matter of environment, where the code is compiled and executing.

So, OO-atom takes idea of object identity, explained in "Elegant Objects" vol 1. sections 2.1, 2.2 as a basis for defining equality semantics between two Atoms. Two Atoms are equal if and only if they are instance of the same class and their fields are equal. Then, it generates these methods for each Atom during the classes instrumentation stage, so details of this comparison remain behind the scenes.

#TODO: exceptions #TODO: tests and assertions