Framework is - Tistory
108
http://www.arload.net
Transcript of Framework is - Tistory
Framework is ..
Framework is…
Douglas C. Schmidt Says..Frameworks define “semi-complete” applicationthat embody domain-specific object structures and functionality.
Class Library Component Architecture
App SpecificLogic
OO Design
EventLoop
DATABASE ADTs
MATH NETWORKING
GRAPHICS GUI
Singleton Strategy
Reactor Adapter
State Active Object
Invocations
Selections
Application Block
Design Pattern
Libraries is..
DATABASE
Singleton
GRAPHICS
Adapter
EventLoop
Reactor
NETWORKING
Active Object
GUI
State
App SpecificLogic
MATH
ADTs
Callbacks
Invocations
Application FrameworkComponent Architecture
But Framework is ..
Why Do You Need Framework?
Avoid Duplication Productivity
Welcome to
My Framework
Journey!
“Framework Engineering”, TechED 2007 Europe
“Framework Design Guidelines” , Addison Wesley
Krzysztof Cwalina
Program Manager on .NET Framework Team
5 Topics..
Organization
Planning
Architecture
Design
Development
DO P A V
The most powerful design tool
O
Project Management Triangle
Scope
Cost Time
O
Project Management Triangle
Organization
O
DO understand how organizational structure, culture, and decision making processes impact your product.
O
Conway's law
If you have 4 groups working on a compiler,
you’ll get a 4-pass compiler.
O
Organization Structure
Software Structure
O
Conway's Clean State Approach
1• Define the business mission
2• Learn the business process from business owners
3• Re-engineer these process to fit the mission
4
• Structure the IT organization to support the reengineered business processes.
O
Your Company Culture Is ..
Voluntary ??O
Familial ??O
Your Company Culture Is ..
Peremptory O
Organizational InfluencesSize of Organization
Small Team
Simple Design
Consistency Design
Focus on 80/20 Rules
O
Large Team
Organizational InfluencesSize of Organization
Powerful Design
Lack Consistency
Remove Requirements
O
Organizational InfluencesOrganization’s Culture/Biases
Customer-Focused
End-2-End Scenarios
O
Organizational InfluencesOrganization’s Culture/Biases
Technology-Focused
Long Lasting Architecture
O
Decision Making Process is..
O
Ensuring we are building the right thing
P
P
Focus: features
Results: stability,
incremental
improvements, not
great end-to-end
scenarios
Peanut Butter
Focus: scenarios
Results: Excitement,
breakthroughs, but
beware of leaving
existing customers
behind
Skyscrapers
P
Moderation (中庸)MileStone = Scenarios + Feature
Planning M1 M2
ReleaseTesting
Feature completeVision statement RTM
Technology Preview Beta 1 Beta 2 RC1
Ensuring the long term health of the framework
A
A
Right Way??Choose right types.
PrimitivesVery little policy (behavior design decisions)
Stable design
Commonly appear in publicly accessible APIs
Almost impossible to evolve/change design;
any design changes have huge breaking change impact on other APIs
Example: Int32, String
A
Definition:Libraries are types that are not passed between components
ExamplesEventLog, Debug,
Easy to EvolveLeave old in, add new one
Beware of duplication!
A
Libraries
Abstractions
Definition:Abstractions are interfaces or classes with unsealed members that are passed between components.
ExamplesStream, IComponent
Hard to Evolve
Unfortunately, pressure to evolve
A
Primitive Oriented Design
A.K.A. “Handle based design” (functional)
Great evolvability, poor usability (sometimes)
Low level stable primitives + high level reusable components with limited dependencies other than to the primitives
E.g. Type.GetType(object) – works, but not as convenient as Object.GetType
A
for primitive.. C# 3.0 New Featurenamespace MyCompany.StringManipulation {
public static class StringExtensions{
public static bool IsNullOrEmpty(this string s){ return String.IsNullOrEmpty(s);
}
}
}
…
using MyCompany.StringManipulation;
string message= “hello world”;
if(message.IsNullOrEmpty()){
Console.WriteLine(“EMPTY”);
}
Component Oriented Design
Rich APIs with lots of features, thus with lots of dependencies
Great usability, poor evolvability
Good for higher level components, not for the core of a platform
A
A
DO Manage Dependencies..
A
Lego, Plug ??
Component is ..
A
.. a set of types that ship and evolve as a unit.
A
Dependency
API
Implementation
Circular
API Dependency
Component A has an API dependency on component B,
if a type in B shows in the publicly accessible API surface of a type in A.
This includes:Base types and implemented interfaces
Generic parameter constraints
Return types and parameters of members
Applied attributes
Nested types
A
Implemenatin Dependency
If a type in A uses a type in B in its implementation.
Hard Dependencies (required to run)Soft Dependencies (optional)
A
Circular Dependency
Component A depends on component B and
Component B depends on component A (even indirectly).
A
Packaging Principle
Package Cohesion PrincipleREP (Release Reuse Equivalency)
CCP (Common Closure Principle)
CRP (Common Reuse Principle)
Package Coupling PrincipleADP (Acyclic Dependencies Principle)
SDP (Stable Dependencies Principle)
SAP (Stable Abstraction Principle)
ARobert C. Martin, Principle of Package Architecture
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
A
Solution is Layering..
A
A
BCL
WPF XML
Reflection
Circular Dependency
A
GUI
CommAnalysis
ProtocolModem
Control
Comm
Error
Database
Creating a new packaging.
A
GUI
CommAnalysis
ProtocolModem
Control
Comm
Error
Database
Message
Manager
A
B
X
Y
Circular Dependency
A
B
X
Y<<interface>>
BY
Adding new interface
Heavy Depedency
A
A
Heavy Dependencies and Testability
// your API
public class Tracer {
MessageQueue mq = new MessageQueue(…);
public void Trace(string message){
mq.Send(message);
}
}
// your customer’s program that is hard to test
Tracer tracer = new Tracer();
public void ProcessOrder(Order order){
tracer.Trace(order.Id);
…
}
Inversion of Control
// your better API
public abstract class TraceListener {
public abstract void Trace(string message);
}
public class Tracer {
TraceListener listener;
public Tracer(TraceListener listener){
this.listener = listener;
}
public void Trace(string message){
listener.Trace(message);
}
}
Dependency Injection
// your customer’s program that is easier to test
Tracer tracer = new Tracer(new FileListener());
public void ProcessOrder(Order order){
tracer.Trace(order.Id);
…
}
// customer’s program that is even easier to test
Tracer tracer = container.Resolve<Tracer>();
public void ProcessOrder(Order order){
tracer.Trace(order.Id);
…
}
Check out DI Containers (a.k.a. IoC Containers): autofac, Castle Windsor, PicoContainer.NET, Spring.NET, StructureMap, Unity, nInject and others.
http://www.nInject.org
DO balance advances with compatibility.
A
Types of “Compatibility”
A
Cross-Version
Backward
Forward
A
Cross-Redist.
A
Define what’s a “breaking change”
This definition depends on the objectiveE.g. Enable portable code between Silverlight and .NET Framework
E.g. Enable cross-version portability?
For example, Silverlight interfaces cannot have less members than .NET interfaces, but concrete types can.
A
AVOID duplication and overlap.
A
A
Problem Space Show and Tell
PLoP – Capable, Productive and Satisfied Patterns for Productivity
http://hillside.net/plop/plop98/final_submissions/P54.pdf
When the new technology is “10x better”
Make sure you understand the impact on the ecosystem
What would happen if the BCL team added a new String?
What’s the migration path for code using the old API?
A
This is where quality happens
D
Is using your framework correctly like…
Running across a desert?
A
DO design APIs by
first writing code samples for the main scenarios
and then
defining the object model to support the code samples.
D
Code Samples
D
Read File
static void Main(string[] args)
{
StreamReader sr = File.OpenText("MyFile.txt");
string s = sr.ReadLine();
while (s != null)
{
s = sr.ReadLine();
Console.WriteLine(s);
}
}
D
static void Main(string[] args)
{
foreach (string s in File.ReadAllLines("MyFiles.text"))
{
Console.WriteLine(s);
}
}
Feedback (Read File)
D
Object Model Listing
D
Framework Design Studio Assembly Exploer
Project -> Add -> Assembly
Download here - http://code.msdn.microsoft.com/fdsD
Framework Design Studio Assembly Review Comment
D
Framework Design StudioCompare API Versions
D
Framework Design StudioCompare API Versions
Red is removed,
Green is added,
Grey means inherited.
D
Framework Design StudioExporting to Microsoft Word
Tools -> Export to Document
DO treat simplicity as a feature.
D
Remove Requirements
Reuse Existing Concepts or APIs
Adjust Abstraction Level
Three Example (Evolving Frameworks)
D
DO measure, measure, and measure!
D
Specification Document: Qualities
Performance GoalsBaseline: What do is the best my API could do?
Measure delta from the baseline
Threat ModelsThreat: What is the worst that my component could do?
Mitigate the threats
Same for many other qualities you want your framework to have
D
THE POWER OF SAMENESS
D
When you pick up your rental car….
Push the seat all the way back
Find an NPR station
Find the exit
Read the manual??
Oh, down to lock…
How to use a key…
Oh, you push the PRESS button…
Who actually needs this data?
You know how to drive your car
All cars work basically the same way
Your rental car is a car
Therefore, you can drive your rental car
That is…
The bits customers get, … or not
V
Branches and Integrations
Main
PU-staging
branch
Feature
branch
Feature
branch
PU-staging
branch
PU-staging
branch
V
AVOID integrating unfinished features.
V
Functional SpecificationDeveloper Design SpecificationTest PlanThreat ModelAPI reviewArchitectural ReviewDependency ManagementStatic AnalysisCode CoverageTesting (Unit and Integration Tests)0 BugsPerformance
V
DO pay your debt.
V
Planning M1 M2
ReleaseTesting
Feature completeVision statement RTM
Technology Preview Beta 1 Beta 2 RC1
Milestone Quality
Milestone Quality (MQ)
Initiatives that are hard to do in regular milestones
Large productivity and efficiency improvements
Infrastructure changes
For example, a new source control system
Refactoring of fragile subsystems
Internal implementation documentation
Bugs backlog
V
DO understand how organizational structure, culture, and decision making processes impact your product.
AVOID peanut-butter in Scenario Based Application.
DO manage your dependencies.
DO balance advances with compatibility.
AVOID duplication and overlap.
DO design APIs by first writing code samples for the main scenarios and then defining the object model to support the code samples.
DO treat simplicity as a feature.
DO measure, measure, and measure!
AVOID integrating unfinished features.
DO pay your debt.
Krzysztof Cwalina, Brad Abrams
Framework Design Guidelines:Conventions, Idioms, and Patterns for Reusable .NET Librarieshttp://channel9.msdn.com/pdc2008/PC58/
http://www.gotdotnet.com/team/fxcop
Douglas C. Schmidt (PLoP Editor, POSA 2, 4 Writter)
JAWS: An Application Framework for High Performance Web Systemhttp://citeseer.ist.psu.edu/81775.html (En)http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=11 (Kr)
Ralph Johnson (GoF , Design Patterns)
Evolving Frameworkshttp://st-www.cs.uiuc.edu/users/droberts/evolve.html (En)http://arload.wordpress.com/2008/09/15/evolvingframeworks/ (Kr)
Robert C. MartinPrinciples of Package Architecture (Design Principles and Design Patterns)
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf (En) http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=108 (Kr)
For Korean People..
Load to Architecthttp://www.arload.net
EvaCast (Online Free Lecture)http://www.evacast.net
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0
대한민국 라이센스에 따라 이용하실 수 있습니다.
This work is licensed under Creative Commons Korea Attribution 2.0 License.
