I've one of my friend that was programming using Delphi and due to increase in demand of .NET in market, he decide to upgrade himself. Here is details of conversation that is done between he and me:
I was hinted by the boss that I will be the mentor of fellow Delphi programmers who want to learn C#. Though I do not consider I has mastered half of what a senior C# programmer should have, I would share some experiences in my learning path.
I am well aware of the mindset of common Delphi programmers, and why we loved Delphi, as I started using Delphi since 1997, moving from C/C++.
I started .NET programming unwillingly in year 2003, in a project of developing some class libraries of ASP.NET. Somethings I felt bad included:
1. .NET provides garbage collection. I spent years to acquire profession of developing memory-leak-free Delphi applications. With such garbage collection, the skills I developed become insignificant. In the first year or two using C#, I kept the habit of releasing objects after uses, though now I understand this is bad practice in .NET. In addition, memory management in large projects particularly distributed applications is always difficult. Leaving memory management to GC will make developers concentrate more on designs and coding, rather than busy house keeping of releasing objects.
2. The libraries of .NET framework look very foreign to me. There are many functions available in Delphi but not in .NET framework. Nevertheless, after .NET 2, apparently Anders the farther of Delphi and C# had altered some conventions of the .NET framework dramatically to appeal to Delphi programmers. No more complaints.
3. High memory usage. Now I understand this is by design in order to lower the cost of memory allocation, and the memory usage is well managed by CLR.
Comparing with programmers from Java and C++, Delphi programmers have the following conveniences when moving to C#:
1. The casing convention is Pascal convention.
2. Since .NET 2, the naming convention of .NET libraries became more appealing to Delphi programmers who may research needed functions in a more speedy manner.
3. The block convention of C# syntax is similar to Object Pascal. So Delphi programmers may read C# codes faster. I have seen some C# programmers from C background insisted on constructing blocks in C style, however, they may have harder time when reading others' C# codes.
Of course Java programmers and C++ programmers may argue that they have more conveniences, as the C# syntax is more similar to the ones of Java and C++, and C# was built on the top of the concept of Java.
I think, a Delphi programmer may treat C# as Delphi in Java syntax flavor at the very beginning of studying, say, when developing a few demo projects to get familiar with basic C# syntax and VS IDE. However, don't let such mindset last long, as I did lasting one year. I think, one or two months is more than enough. Otherwise, when you review conventional C# codes written by others with more experiences, you will feel very awful.
There's nothing to prevent you from writing C# codes in Object Pascal style so you feel comfortable, however, staying in your comfort zone will lead to 4 major drawbacks:
1. You do not take advantages of those C# syntax designed by Anders.
2. Code Analysis will complain bitterly. The warnings from Codes Analysis come with good reasons: they are the collective wisdom of programmers around the world over years.
3. You will be re-inventing the wheel when developing enterprise applications, as many features have already been available in .NET Framework. Without mindset change for new style, you will be basically writing Delphi codes in C# syntax running on VM, but without using the powers of .NET Framework.
4. It will be hard for you to read conventional C# codes in order to learn from others.
Common Misconception from the mindset of RAD:
1. Code Analysis find errors for you, so you write correct codes faster. A handful numbers of defects found by Code Analysis became compiler errors, that was, MS put some of the analysis rules into the parser of .NET compiler. However, code analysis is mostly for locating vulnerable codes and improving maintainability. Without doing code analysis, your codes may still run well in an ivory tower. If you buy the concept of code review, code analysis is your good friend as it is automatic code review. The machine is doing code review for you, so you can concentrate on those vulnerabilities or defects which can not possibly checked by the machine.
2. Unit test will slow programmers down.There are many text books about the productivity you can get from unit tests. My experience: unit test force you to make good designs which are generally friendly to unit tests; unit test give you assurance and confidence when you move forward during bug fixing, refactoring and adding new features.
The following factors support the importance of mindset change:
1. The sole soul of Delphi is RAD, in contrast, some of the souls of C# .NET are agile and enterprise architecture, though VS .NET well support RAD. Borland/Inprise tried to transform Delphi toward enterprise architecture, but failed, partially because of the soul. There are tons of discussion in the Internet about RAD, though I was a big fan of RAD.
2. The elements illustrated below which are generally weak or absent in Delphi except Delphi 2010. And you should search MSDN as well as other resources to learn the accurate concepts of these elements.
Configuration
Delphi programmers generally use INI file, database tables or free form XML to persist settings. .NET provide a solid framework of configuration, and on the top of that, MS also provide an application block for configuration. And, you can build derived classes of ISettingsProvider to interface with settings stored in legacy storage.
Configuration has significant impact on design and deployment. In many Delphi applications, a configuration file is generally for storing setting used by the business logic of the applications. In .NET, a configuration is always used by CLR for binding components together.
Many .NET technologies are based on the combination of configuration and reflection, for example, unit tests.
The library of configuration is vast. Studying the library is an on going process.
Reflection
Programmers have been long using variety of design patterns to remove couplings, and reflection provides another paradigm for removing coupling, though reflection is not only for removing coupling.
Many of the .NET technologies are built on the foundation of reflection, such as attribute, configuration binding, and unit tests etc.
Assembly
Actually Delphi has similar concept: Package or Borland Package Library (BPL). A BPL file is a dll file and supports object oriented interfacing.So you may consider a .NET assembly is an advanced "BPL" file with byte codes rather than machine codes. In addition, an assembly contain a chunk of meta data describing the assembly for various purposes.
Short life cycle
There are many text books about the advantage of making objects have short life cycle. In Delphi as well as other languages without automatic garbage collection, it is hard to implement a design encouraging short life cycle.
GC
While GC is for automatic garbage collection, you should still avoid unintended memory build-up which is generally caused by a long live object holding up short live objects unnecessarily.
GAC
Global Assembly Cache is a special directory managed by .NET framework along with Windows kernels. Basically assemblies installed in GAC are trusted because only admin can install them there. .NET CLR will always search for needed assemblies in GAC first then elsewhere.
Resource management
While GC will dispose unused objects automatically, however, when the collection operates is not deterministic. GC is for managing memory, not for resources which are provided by the OS and managed by OS. You as a programmer should be responsible for releasing unused resources ASAP:
1. A class which owns a resource MUST implement IDisposable.
2. When using an object of the class, it is desirable to put it within a Using statement which will guarantee the resource used is disposed no matter what happen even if an exception is raised withing the Using block.
Without conforming to these 2 guidelines, you will see your program runs out of resources soon when requests to resources (e.g. internet connections) become frequent, for example, during unit test or stress test.
Attributes
Attributes are basically meta data associated with classes, properties or methods. It is up to the CLR, framework codes or your domain specific codes to interrupt the attributes and react. Attributes give loose couplings and great flexibility. Your first encounter with Attributes would be those in unit tests, such as TestClassAttribute and TestMethodAttribute.
Unit tests/TDD
There are many articles and books about unit tests and Test Driven Development. And MS Test provides powerful supports and conveniences to unit tests. Surely codes under mouse won't be good for testing, neither be good design at all. In general, a good design is easy to test automatically.
While constructing test codes takes time, however, it will greatly reduce debugging and speed up the whole development. When you add new features to your product, you will have less worry about whether newly introduced codes will break the product, because your test codes will likely be broker first. Evaluating new codes against unit tests is easier that evaluating new codes against the whole product.
Microsoft .NET programming guidelines
Borland had provided a few pages of programming guidelines, mostly focusing on naming conventions and styles. And much of the context is integrated into a few implementations of Delphi formaters.
Microsoft has provided more than 100 pages of .NET programming guidelines, and much of the context is integrated into Code Analysis.
Code Analysis
It is not for finding bugs for you. Please check Wikipedia about Code Analysis.
Components
"Programming .NET Components" by Lowy is a book must read after you have used C# in commercial projects for half year.
Common Object Model/Interoperability
COM is one of the basic glue between Windows applications, and the other is Windows messages which is hard to use. In native Windows, majority of coordination between applications and components within a machine is implemented through COM. So .NET applications running on CLR should not give up the coordination with other applications running on native Windows. Interoperability is the bridge between 2 environments.
After all, I think the most important thing of all is changing mindset. It took me one year or two to change. Hopefully through reading this post you will take less time.
To be continued and updated ...
No comments:
Post a Comment