Help your helper classes by defining their context & responsibility at class design time, and applying refactoring techniques.
Each class should state clearly what are its responsibilities and roles in the context it is located in.
Appending the keyword helper to classes is getting misused and becoming a bad habit. Imagine having code with 30 or more helper classes, first people would start thanking language designer that they made use of namespaces, still this does not remove the ambiguity from helper classes and the duplication of code that is occurring in them.
The idea of a class to be helper to another class bounds its responsibility to helping a specified class or set of specified classes, and this causes less use of helper class in libraries or small frameworks, because most of the time there is no specified role for the helper class except helping and this is an ambiguous role because it could be anything!
This problem can be solved by defining unambiguous responsibilities and roles to the class, and naming the class with a name that reflects its responsibilities and roles, in addition that the class exposed functions and methods should satisfy the class responsibilities and roles. I recommend applying refactoring techniques available on http://www.refactoring.com/catalog/index.html, the following refactoring techniques are the most beneficial for such scenario "Extract Superclass", "Extract Class", "Extract Subclass", "Move Class".
All classes communicate & help each other under specified roles and responsibilities, these factors are the constraints that make system responsibilities and roles clear and maintainable. Misusing the helper concept causes the formation of an ambiguous system.
Take the following very basic and simple example:
We have a class called ‘Help’ that is responsible for viewing a special help file, and we have another class that helps the ‘Help’ class, I am going to name it as some programmers are doing these days, we will call the class ‘HelpHelper’ it saves and reads special help files. This is an example of bad naming that does not reflect the class responsibilities and roles.
While we can name the preceding classes as the following and specify unambiguous responsibilities and roles:
The ‘Help’ can be named ‘HelpViewer’ that has the responsibility and role of viewing a special help file, and the ‘HelpHelper’ helper class to ‘HelpFileManager’ that is responsible for managing the saving and reading, this a clear specification, that allows better maintainability and clear extension of classes in a framework or library.
My advice is to decrease the use of naming classes as helpers and work on specifying unambiguous responsibilities and roles for classes, to allow people working in this domain to have better understanding of the classes they are dealing with, for maintenance, testing, extendibility, effective use reasons.
Is there a class named with the Helper keyword in .net Framework? And if there exists, what is the number?
Sincerely
Rabeeh Abla
Download Files: Presentation GOF Pattern Template GOF Code Examples
Design patterns are recurring sequences and best practices for repeated scenarios in software development over the years.
They are common recurring design rules
We need software design patterns to define constraints on software architecture, in order to achieve the following goals:
1- Define and manage software extendibility
2- Bind to standards, eliminate ambiguity
3- Reduce maintenance cost
The idea is to maintain change, and enforce rules on a set of entities to define their behavior.
Download presentation and source code for more information.
Regards
Rabeeh Abla
SilverLight specification and use of XAML, drives one to inspect this platform. The use of standards is what enables manageable integration, and improves software maintenance. Having such platform integrated in .Net framework and available for developers, encourages one to experiment a little by using it.
Mesh viewers are common in CAD, and there are many available tools and libraries to develop and view complex mesh nets. In short a mesh is a net of connected faces, and a face is a set of vertices.
I created a humble very basic .Net Mesh Library that is free for anyone interested in improving and using it. This library can be used in .Net application, all that changes is the way of connecting two points i.e. drawing a line.
In windows application you can draw a line by using the Graphics object method DrawLine, in SilverLight you draw a line by creating a Line object and adding it to the main Canvas.
void engine_OnDrawLine(MeshSilverlightLibrary.Common.Point start, MeshSilverlightLibrary.Common.Point end)
{
Line l = new Line();
l.X1 = (float.IsNaN(start.X) ? 0 : start.X);
l.Y1 = (float.IsNaN(start.Y) ? 0 : start.Y);
l.X2 = (float.IsNaN(end.X) ? 0 : end.X);
l.Y2 = (float.IsNaN(end.Y) ? 0 : end.Y);
l.Stroke = new SolidColorBrush(Colors.Blue);
l.StrokeThickness = 1;
LayoutRoot.Children.Add(l);
}
Regards
Rabeeh Abla
Design patterns are recurring sequences, built-in .Net patterns are scattered over the framework.
In practice following standard software patterns will help to achieve a more standard code, that is manageable, and understandable by a bigger set of software programmers/developers and architects.
For example the data adapter factory, that enables the creation of specific DBMS adapters. This centralized class helps in establishing a strong data layer, that supplies a more generic way to communicate with business layer.
For example:
Imports System.Data.Common
dbPFactory = DbProviderFactories.GetFactory(“FactoryName”)
adapter = dbPFactory.CreateDataAdapter()
Uml design of generic Adapter class, that makes use of 'DbProviderFactories' factory, and DbProviderFactory, to create a generic layer.
Fig -1-
In simple technical english, a factory pattern is responsible for managing and creating product class instances from a base class that has an increasing or more than one child classes. The DbProviderFactories is a factory of factories, that manages the dbms adapters in .Net 2.0. Building a class wrapper over this architecture and supplying the correct parameters will enable the direct generation of specified data adapters to communicate with most of the standard DBMS in the market.
The following is a code example of creating an adapter to connect to Access database
public DataTable GetData()
{
GenericAdapter.GenericAdapter genericAdapter = null;
ConnectionStringInfo conInfo = new ConnectionStringInfo();
DataTable table = null;
//Supplying parameters to connect to Access db
conInfo.DataBaseFilePath = @"c:\db.mdb";
conInfo.ProviderName = "Microsoft.Jet.OLEDB.4.0";
conInfo.DataSource = "{FilePath}";
genericAdapter = new GenericAdapter.GenericAdapter("System.Data.OleDb");
if (genericAdapter.SetConnectionString(conInfo))
{
table = genericAdapter.ExecuteTableCommand("MyTable"); //return table data
}
return table;
}
Singleton pattern is implemented in many places in the .net framework, single instance window applications, also in remoting we deal with singleton classes.
A singleton pattern can be achieved by forbidding the creation of direct class instance, using the constructors. This is done by making constructors private, and preventing the user from creating an instance of the class.
This enables only the creation of instances from class scope. To enable single instance in memory we use static or shared reference to the class, we make it private to prevent public access, and we set it to NULL.
We add a static or shared function that checks if the class static reference is NULL, if NULL an instance is created, otherwise the previous instance is returned.
The .Net frame makes good use of the proxy pattern , that is a mediator between the real object and the client object. When applying proxy design pattern, the proxy class provides the same services as the real object. That is they inherit from same base class, or apply the same interface. Proxy classes are used in remoting, and when communicating with services.
Such patterns define the road map for extending a framework, using these patterns will allow your applications benefit a great deal, in extendability and code maintenance.
This was an introduction to .Net Design patterns, an example of using DBFactory to create a generic adapter can be downloaded from this page.
Regards
Rabeeh Abla