27.7.13

POSA2 Notes (1)

Inherent and accidental complexities:

  • Inherent complexities
    • (POSA2) Inherent complexities arise from fundamental domain challenges, such as dealing with partial failures, distributed deadlock, and end-to-end quality of service(QoS) requirements.
  • Accidental complexities
    • Accidental complexity - Wikipedia, the free encyclopedia
    • (POSA2) Accidental complexities arise from limitations with software tools and development techniques, such as non-portable programming APIs and poor distributed debuggers.
    • Ironically, many accidental complexities stem from deliberate choices made by developers who favor low-level languages and tools that scale up poorly when applied to complex concurrent and networked software.

Topics (POSA2)

  • Connection establishment and service initialization.
  • Event demultiplexing and event handler dispatching.
  • Interprocess comminication (IPC) and network protocols.
  • Primary and secondary storage management and caching.
  • Static and dynamic component configuration.
  • Concurrency and synchronization.

Challenges of Concurrent and Networked Software (POSA2)

  • Service Access and Configuration
    • Accidental complexities for using low-level operating system APIs. Key design challengs for infrastructure networking or system programs center on minimizing the accidental complexities without sacrificing performance:
      • Excessive low-level details.
      • Continuous rediscovery and reinvention of incompatible higher-level programming abstractions
      • High potential for errors
      • Lack of portability
      • Steep learning curve
      • Inability to scale up to handle increasing complexity.
    • A key design challenge at higher-level distributed object computing applications centers on ensuring that clients do not access invalid or unauthorized component service roles.
    • Supporting the static and dynamic evolution of services and applications is another key challenge in networked software system.
      • Interfaces to and connnectivity between component service roles can change, often at run-time, and new service roles can be implemented and installed into existing components.
      • Distributed system performance can be improved by reconfiguring service load to harness the processing power of multiple hosts.
    • Another design challenge is to ensure that an entire system need not be shutdown, recompiled, relinked, and restarted simply because a particular service role in a component is reconfigured or its load is redistrubted.
    • It is even more challenging to determine how to access services that are configured into a system 'on-demand' and whose implementations are unknown when the system was designed originally.
  • Event Handling
  • Concurrency
  • Synchronization
  • Others

26.7.13

NIO/NIO2


Inappropriate Intimacy

Just realize that my understanding of Inappropriate Intimacy was incorrect. I thought if many classes were coupled to used a specific class, it is inappropriate intimacy. However, this is not.

Inappropriate Intimacy means one class is implemented upon the details of another class.

In Refactoring the book:


  • Sometimes classes become far too intimate and spend too much time delving in each other's private parts.
  • We may not be prudes when it comes to people, but we think our classes should follow strict, puritan rules.
This is how the name came from. 

By reading the book again, I find that I really like the language of the book. I used to read the Chinese version, but the English version is better.

  • Move method/move field
  • Change Bidirectional Association to Unidirectional
  • Extract class
  • Hide Delegate
    • Hide Delegate
    • The example in the book of "Hide Delegate" is very intuitive. You can create a delegation method getManager() for Person, instead exposing its Department (private part) for accessing his manager. 
  • Replace Delegation with Inheritance. (I think this should be: replace inheritance with delegation)

20.7.13

Off-heap Cache


Garbage Collection in Java