Multi View Constructed right

Eduardo M. FleuryBossaConference 2010 - Manaus

Multi View Constructed rightEduardo Madeira FleuryBossaConference 2010 - Manaus

Agenda

1 Introduction

2 Proposed architecture

3 Example

4 Real world issues

5 Conclusion

Everybody wants code that is

• Easy to understand and learn• Easy to maintain• Easy to extend or modify• Less prone to bugs

We need code that

• Can be created in parallel by the team• Assume look and feel of multiple platforms• Is future-proof regarding new GUI technologies

Need to support new devices

• There is a lot more than re-compiling• Screen size and viewing distance• Environment of use• Looks / Platform integration• Input methods

Need to support new technologies

• Qt widgets• Qt canvas (Graphics View)• Qt Quick (QML)• Other toolkits

A good architecture helps

• Reduce the number of code-paths• Define relevant / semantic components• Do not define too many components• Define good component API and keep them independent

Proposed architecture

Identify important concepts in your app

• Access data• Use data• Keep application state• User input• User output

Create component to access data

• Handle DBs• Parse file meta-data (EXIF, ID3, etc)• Access different data sources (network, other apps)• Watch for data modification

Create component to handle program ’core’

• Use data (play a song, interpolate an image)• Keep application state• Respond to high level user requests• Provide high level user output data

Create component to handle user interaction

• Listen to low level user input events• mouse click, keyboard pressed, remote control• Output information to user• Draw song title on the screen, beep when newmessage arrives

Component relationship

Figure: Relationship

Expected result

• Each component can be created in parallel by different people• Interface component can be modified to support new device• Interface component can use new technologies

Example

Component relationship

Figure: Relationship

Real world issues

Difficulties arise in practice

• Over-engineering• Excessive complexity• Poorly chosen interfaces / slice points• Promiscuity between components• Too much indirection in data flow

Over-engineering

• We are brilliant at identifying patterns• We fail miserably when dealing with large number of items• Harder to make mental model of, or harder to understand• Harder to maintain and extend

Over-engineeringAsk yourself

• What is the use case?• What problem am I trying to solve?• What potential of growth does this application have?• Do I really need that now?

Excessive complexity

• Default use cases are usually easy to handle• Corner cases together mean lots of code• Are such corner cases worth the extra effort?• Lots of features, lots of bugs too...

Excessive complexityAsk yourself

• Some people are fetishists about useless features, avoid that!• Avoid bloatness as a whole• Define priorities, use your time wisely• Remember:• What is the use case?• What problem am I trying to solve?• Do I really need that now?

Poor component interfaces

• Leads to an ’artificial’ division• Require data to be moved around• Poses obstacles to component replacement• Harder to be used and mentally modeled

Poor component interfacesAsk yourself

• Public API should be thoroughly thought of• Look at the problem from above• Try and make analogies with real world situations• Find a whiteboard, think before you code• Discuss your architecture with your peers

Components inter-dependency

• Components need to include other components• Components are not replaceable• Programmers cannot look at one class and understand it• Some patterns are well known and easier to recognize

Bad Component relationship

Figure: Bad Relationship

Components inter-dependencyAsk yourself

• Is this class a provider or consumer?• Use Qt Signal/Slot do decouple components• Consider an abstract public API

Data-flow indirection

• Data goes through several classes to reach its destination• One reading the code needs to imagine where does that come from• API gets dirty due to methods that mostly move data around• It can also be inefficient performance-wise

Data-flow indirectionAsk yourself

• Think about your whole application• Where is data coming from? Where is it going to?• Consider a high throughput link between consumer and producer• Find a good compromise between interdependence and indirection

Conclusion

• There’s a need for good architectures• Good ideas exist• Many projects suffer from bad implementation of such ideas• Learn from yours and other’s mistakes• Homework: Find an useless feature in your favorite software

Questions

Questions ?

Thank you!eduardo.fleury@openbossa.org

blog.eduardofleury.com