The Pain Points of C#
•Download as PPTX, PDF•
0 likes•913 views
Copy: https://docs.google.com/presentation/d/1eOi0wHcINe6WfhCfvxl6j8qbP-fko8NuPb-vgNMrTO0/edit?usp=sharing
Recommended
More Related Content
What's hot
What's hot (19)
Similar to The Pain Points of C#
Similar to The Pain Points of C# (20)
More from Tuomas Hietanen
More from Tuomas Hietanen (14)
Recently uploaded
Recently uploaded (20)
The Pain Points of C#
- 1. Object Oriented Programming Pain Points
- 2. Database General Architecture(Simplified) Data Access (O/R) User Interface Domain Model User Interface Data Model Business Logics User Interface Logics Service layer Debug
- 3. Needed Changes in Maintenance
- 4. The shape of objects have to be specified before the functionality
- 5. Object
- 8. The pain points of C#
- 9. Immutable property public class MyObject { private readonly string myproperty; public string MyProperty { get{ return myproperty; } } public MyObject(string prop) { myproperty = prop; } }
- 10. Type Definitions var list = new List<List<int>>{ new List<int>{1,2,3}, new List<int>{4,5,6}, }; Ok! Noise! Func<Func<int, List<int>, string>, Func<int, List<int>>, int, string> S = (x, y, z)=> x(z, y(z));
- 11. F# Syntax type MyObject(prop:string) = member x.MyProperty = prop let list = [[1;2;3];[4;5;6]] let S x y z = x z (y z) Ok!
- 13. void is not a type
- 14. There is no “either-or”-type
Editor's Notes
- Every tier has an Interface and a concrete class Concrete class is not found easily, it may be resolved with IoC Interfaces between layers have to be constant Usually layers are “useless” pass-through-layers Maybe some null-checks (and object-mapping to another-layer-objects) OMG Ponies: http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx
- Maintenance code changes are more expensive than development There are two main reasons to change code in maintenance: Business-need change, role change of a Domain-objectBug: Code seems to be different than how program works In any case, we have serious problems
- Objects have been said to be natural model for humans. Have to be designed bottom-up (details first), although specifications are made the opposite way.
- Here is a container… Then we will need manager, provider, factory, …And interfaces of course…What this actually does?
- ”Common” will never work, because we don’t know the future needs The only working solution for common functionality is Reflection No compile time error checking There is a reason why there is a type system in .NET!
- - How hard can it be??? Noise! Basic property { get;set; } is easy. But it is hard to make objects, which someone else coulnd’t set to invalid state.
- The function in the bottom is actually real… :-)
- The new language and thesmaller syntax and better libraries are actually not the main point.F# also has higher level of abstraction. Like C-language has higher level of abstraction than assembly-language.
- Of course, with Java, you couldn’t do anything like this:The “generics” of Java are just “syntactic sugar”, the compiler will optimize those away
- - This would be ok, if the language would separate side effects in some way. However a Func can also cause a side effect. For this reason: F#-functions are not compatible with C#, Real pattern matching won’t work F# list handling has more expression power than LINQ. In addition, separating lists to different IEnumerables is hard (mostly possible only with a GroupBy-trick).
- Drifting to Reflection: performance hit, loss of compiler time error checks