Domain Driven Design

The ultimate purpose of software is to serve users. But first it has to serve developers. This is especially true in a process that emphasizes refactoring. As the program evolves, developers will rearrange and rewrite every part. They will integrate the domain objects into the application and with new domain objects. Even years later, maintenance programmers will be changing and extending the code. People have to work with this stuff.

Domain Driven Design

When a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of MODEL-DRIVEN DESIGN – that the model supports an effective implementation and abstracts key insights into the domain – is half gone, and the resulting models will be impractical. Meanwhile, if the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Finally, the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a MODEL-DRIVEN DESIGN.

Decisão

Decidir implica optar por uma alternativa de ação em detrimento de outras disponíveis, em função de preferências, disponibilidades, grau de aceitação do risco etc. Nessa visão, decidir antecipadamente constitui-se em controlar o seu próprio futuro. Essa é uma visão bastante proativa no que se refere ao processo de gestão de certa organização. (ANSOFF, 1977, p.4).

Mapas

"Não nascemos com mapas. Temos de desenhá-los, e esse desenho requer esforço. Quanto mais esforço fizermos para apreciar e perceber a realidade, maiores e mais detalhados serão nosso mapas. Mas muitos não querem fazer esse esforço. Seus mapas são pequenos e incompletos, suas visões do mundo, estreitas e ilusórias"

M Scott Peck

Tim Minchin - The Fence

Donkey Kong Country - Aquatic Ambience

Urban computing

Urban computing is a process of acquisition, integration, and analysis of big and hetero- geneous data generated by diverse sources in urban spaces, such as sensors, devices, ve- hicles, buildings, and humans, to tackle the major issues that cities face (e.g., air pollu- tion, increased energy consumption, and traffic congestion).

I have stood on the shoulders of giants

"Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central problem we face in all of computer science is how we are to get to the situation where we build on top of the work of others rather than redoing so much of it in a trivially different way. Science is supposed to be cumulative, not almost endless duplication of the same kind of things".

Richard Hamming 1968 Turning Award Lecture 

Solitude

My name it means nothing, my fortune is less My future is shrouded in dark wilderness Sunshine is far away, clouds linger on Everything I posessed, now they are gone  Oh, where can I go to and what can I do? Nothing can please me only thoughts are of you You just laughed when I begged you to stay I've not stopped crying since you went away  The world is a lonely place, you're on your own Guess I will go home, sit down and moan Crying and thinking is all that I do Memories I have remind me of you

The Decision Hierarchy

Decision Essentials

Beckett - A Rainbow's Gold (Old Grey Whistle Test 1974)

Karn Evil 9 - Emerson, Lake & Palmer

Emerson, Lake & Palmer - Lucky Man

Triumvirat - Spartacus

Twisted Sister - We're Not Gonna Take It

Iron Maiden - For The Greater Good Of God - piano cover

Effective Java (Remarked) - Serialization

Item 74: Implement Serializable judiciously (design, portability, performance, scalability)

A major cost of implementing Serializable is that it decreases the flexi- bility to change a class’s implementation once it has been released. A second cost of implementing Serializable is that it increases the likeli- hood of bugs and security holes. A third cost of implementing Serializable is that it increases the testing burden associated with releasing a new version of a class. Implementing the Serializable interface is not a decision to be under- taken lightly. Classes designed for inheritance should rarely implement Serializable, and interfaces should rarely extend it. Inner classes (Item 22) should not implement Serializable. To summarize, the ease of implementing Serializable is specious. Unless a class is to be thrown away after a short period of use, implementing Serializ- able is a serious commitment that should be made with care. Extra caution is war- ranted if a class is designed for inheritance. For such classes, an intermediate design point between implementing Serializable and prohibiting it in sub- classes is to provide an accessible parameterless constructor. This design point permits, but does not require, subclasses to implement Serializable.

When use? always.

Item 75: Consider using a custom serialized form (design, portability, performance, scalability)

Do not accept the default serialized form without first considering whether it is appropriate. The default serialized form is likely to be appropriate if an object’s phys- ical representation is identical to its logical content. Even if you decide that the default serialized form is appropriate, you often must provide a readObject method to ensure invariants and security. To summarize, when you have decided that a class should be serializable (Item 74), think hard about what the serialized form should be. Use the default serialized form only if it is a reasonable description of the logical state of the object; otherwise design a custom serialized form that aptly describes the object.

When use? always.

Item 76: Write readObject methods defensively (design, portability, performance, scalability)

When an object is deserialized, it is critical to defensively copy any field containing an object reference that a client must not possess. To summarize, anytime you write a readObject method, adopt the mind-set that you are writing a public constructor that must produce a valid instance regard- less of what byte stream it is given. Do not assume that the byte stream represents an actual serialized instance. 

When use? always.

Item 77: For instance control, prefer enum types to readResolve (design, portability, performance, scalability)

To summarize, you should use enum types to enforce instance control invariants wherever possible. If this is not possible and you need a class to be both serializable and instance-controlled, you must provide a readResolve method and ensure that all of the class’s instance fields are either primitive or transient.

When use? always.

Item 78: Consider serialization proxies in stead of serialized instances (design, portability, performance, scalability)

In summary, consider the serialization proxy pattern whenever you find your- self having to write a readObject or writeObject method on a class that is not extendable by its clients. This pattern is perhaps the easiest way to robustly serialize objects with nontrivial invariants.

When use? always.

Effective Java (Remarked) - Concurrency

Item 66: Synchronize access to shared mutable data (stability)

In summary, when multiple threads share mutable data, each thread that reads or writes the data must perform synchronization. Without synchronization, there is no guarantee that one thread’s changes will be visible to another. The penalties for failing to synchronize shared mutable data are liveness and safety failures. These failures are among the most difficult to debug. 

When use? when you need to avoid dirty-reads.

Item 67: Avoid excessive synchronization (stability, performance)

As a rule, you should do as little work as possible inside synchronized regions. Obtain the lock, examine the shared data, transform it as necessary, and drop the lock. 

When use? always in threads that you do not need to avoid dirty-reads.

Item 68: Prefer executors and tasks to threads (design, stability)

The Executor Framework also has a replacement for java.util.Timer, which is ScheduledThreadPoolExecutor. While it is easier to use a timer, a scheduled thread pool executor is much more flexible. A timer uses only a single thread for task execution, which can hurt timing accuracy in the presence of long- running tasks. If a timer’s sole thread throws an uncaught exception, the timer ceases to operate. A scheduled thread pool executor supports multiple threads and recovers gracefully from tasks that throw unchecked exceptions.

When use? always.

Item 69: Prefer concurrency utilities to wait and notify (design, stability)

In summary, using wait and notify directly is like programming in “concurrency assembly language,” as compared to the higher-level language provided by java.util.concurrent. There is seldom, if ever, a reason to use wait and notify in new code. If you maintain code that uses wait and notify, make sure that it always invokes wait from within a while loop using the standard idiom. The notifyAll method should generally be used in preference to notify. If notify is used, great care must be taken to ensure liveness.

When use? always.

Item 70: Document thread safety (design, readability)

To summarize, every class should clearly document its thread safety proper- ties with a carefully worded prose description or a thread safety annotation. The synchronized modifier plays no part in this documentation. Conditionally thread-safe classes must document which method invocation sequences require external synchronization, and which lock to acquire when executing these sequences. If you write an unconditionally thread-safe class, consider using a private lock object in place of synchronized methods. This protects you against synchronization interference by clients and subclasses and gives you the flexibility to adopt a more sophisticated approach to concurrency control in a later release.

When use? always.

Item 71: Use lazy initialization judiciously (performance, stability, scalability)

In summary, you should initialize most fields normally, not lazily. If you must initialize a field lazily in order to achieve your performance goals, or to break a harmful initialization circularity, then use the appropriate lazy initialization technique. For instance fields, it is the double-check idiom; for static fields, the lazy initialization holder class idiom. For instance fields that can tolerate repeated ini- tialization, you may also consider the single-check idiom.

When use? it depends pretty of context. Is hard to define when.

Item 72: Don’t depend on the thread scheduler (design, stability, readability)

In summary, do not depend on the thread scheduler for the correctness of your program. The resulting program will be neither robust nor portable. As a corollary, do not rely on Thread.yield or thread priorities. These facilities are merely hints to the scheduler. Thread priorities may be used sparingly to improve the quality of service of an already working program, but they should never be used to “fix” a program that barely works.

When use? always.

Item 73: Avoid thread groups (design)

To summarize, thread groups don’t provide much in the way of useful functionality, and much of the functionality they do provide is flawed. Thread groups are best viewed as an unsuccessful experiment, and you should simply ignore their existence. If you design a class that deals with logical groups of threads, you should probably use thread pool executors.

When use? always.

Effective Java (Remarked) - Exceptions

Item 57: Use exceptions only for exceptional conditions (safe, stability)

The moral of this story is simple: exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow. 

When use? always.

Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors (safe, stability)

Use checked exceptions for conditions from which the caller can reasonably be expected to recover.  Use runtime exceptions to indicate programming errors. Therefore, all of the unchecked throw- ables you implement should subclass RuntimeException (directly or indirectly).

When use? always.

Item 59: Avoid unnecessary use of checked exceptions (safe, stability)

Checked exceptions are a wonderful feature of the Java programming language. Unlike return codes, they force the programmer to deal with exceptional conditions, greatly enhancing reliability.

When use? always.

Item 60: Favor the use of standard exceptions (safe, stability)

One of the attributes that most strongly distinguishes expert programmers from less experienced ones is that experts strive for and usually achieve a high degree of code reuse. Finally, be aware that choosing which exception to reuse is not always an exact science, as the occasions for use in the table above are not mutually exclusive.

When use? always.

Item 61: Throw exceptions appropriate to the abstraction (safe, stability)

Where possible, the best way to deal with exceptions from lower layers is to avoid them, by ensuring that lower-level methods succeed. In summary, if it isn’t feasible to prevent or to handle exceptions from lower layers, use exception translation, unless the lower-level method happens to guarantee that all of its exceptions are appropriate to the higher level.

When use? it depends.

Item 62: Document all exceptions thrown by each method (safe, stability)

Always declare checked exceptions individually, and document precisely the conditions under which each one is thrown using the Javadoc @throws tag. In summary, document every exception that can be thrown by each method that you write. This is true for unchecked as well as checked exceptions, and for abstract as well as concrete methods. 

When use? always.

Item 63: Include failure-capture information in detail messages (safe, stability)

To capture the failure, the detail message of an exception should contain the values of all parameters and fields that “contributed to the exception.”

When use? always.

Item 64: Strive for failure atomicity (safe, stability)

Generally speaking, a failed method invocation should leave the object in the state that it was in prior to the invocation.

When use? always.

Item 65: Don’t ignore exceptions (safe, stability)

While this advice may seem obvious, it is violated often enough that it bears repeat- ing. When the designers of an API declare a method to throw an exception, they are trying to tell you something. Don’t ignore it! It is easy to ignore exceptions by surrounding a method invocation with a try statement with an empty catch block.

When use? always.