Wired com Any advice for young programmers Stroustrup

Wired. com: Any advice for young programmers? Stroustrup: I guess giving advice is easy compared to taking it. Know your fundamentals (algorithms, data structures, machine architecture, systems) and know several programming languages to the point where you can use them idiomatically. Know some non-computer field of study well — math, biology, history, optics, whatever. Learn to communicate effectively in speech and in writing. Spend an unreasonable amount of time on some difficult topic to really master it. Try to do something that might make a difference in the world. Taken from an interview with Bjarne Stroustrup: http: //www. wired. com/thisdayintech/2010/10/1014 cplus-released/

Logical Architecture

Logical Architecture • Logical Architecture – the large-scale organization of the software classes into packages, subsystems, and layers • Layer – a grouping of classes, packages, subsystems that has cohesive responsibility for a major aspect of the system

Logical Architecture • Typical layers in an object-oriented system: – User Interface (UI) – Application logic and domain objects (domain layer) – Technical services • Note: UML can be used to draw package diagrams

Fig. 13. 2

Guideline: Design with layers • Organize logical structure of system into discrete layers of distinct related responsibilities • Collaboration and coupling is from higher to lower layers; lower-to-higher coupling is avoided

Guideline: Design with layers • Benefits of using layers (p. 204): – Separation of concerns – Related complexity is encapsulated and decomposable – Can replace a layer with new implementation with little disruption – Lower layers contain reusable functions – Some layers can be distributed – Aids in development by teams Key: separation of concerns

Guideline: Design with layers • Domain layer – application logic layer that contains domain objects – Where domain model get realized • Layers vs. partitions – Layers are horizontal slices – Partitions are vertical compartments within a layer

Fig. 13. 6

Guideline: The Model-View Separation Principle • Model-view separation principle – Do not connect non-UI objects (domain objects – the model) directly to UI objects (the view) – Do not put application logic in the UI elements • Model = the domain layer • View = UI objects • Model objects should not have direct knowledge of view objects (however, observer pattern accommodates this)

Guideline: The Model-View Separation Principle • Domain layer – encapsulates information and behavior related to application logic • UI layer – only responsible for input, output, and catching GUI events • Why? Review motivations p. 210

Relation between SSDs, System Operations, and Layers • The messages sent from UI layer to domain layer will be messages in SSDs • SSDs define the public interface (the API) of the domain layer (model)

Fig. 13. 8