Courtesy: Scott Bain.
Often it is thought that Design patterns are a set of tools that helps to solve a problem. If one pattern does not provide the solution then it would be another, and so on until we keep finding the right pattern. But that is a wrong interpretation for how the design pattern needs to be identified for use. The right way of identification would be to carefully observe the problem in hand, which would reveal the pattern in itself. And this would be the best way to identify the pattern to use for solving the problem.
But how exactly are Design patterns helpful in the design of software?
Design patterns are a high level thought process for solving the problem, abstracting the implementation details which make the problem at hand more approachable thereby depriving the right design.
So what does Design pattern exactly help with?
The Design patterns are helpful to bring the risks salient enough for one to decide on how to approach a solution.
Showing posts with label design. Show all posts
Showing posts with label design. Show all posts
Tuesday, July 28, 2009
Thursday, January 15, 2009
Too much overloading, OOPs
Here is a scenario I encounter often; right, people think they are writing a good Object Oriented programming if it has different methods that are overloaded. The idea is that, others can consume one or the other method based on their need, by writing such overloaded methods I give you more flexibility. And by doing so, this becomes a good OOP. Guess what, essentially all they are doing is adding more complexity and clutter in code.
As every statement needs a justification, let's see the scenario:
I have a protocol that takes n parameters, in order for a consumer to run his test case he would need to set up some parameters as an initial condition.
say there are 3 parameters for simplicity, a, b, c.
public settings Initialize();
public settings Initialize(a,b);
public settings Initialize(b,c);
public settings Initialize(a,c);
...
In a real world obviously the parameters could grow in size. So what happens when a 4th parameter is added say d. You have to write overloaded methods encompassing the different combinations. so it becomes 3 X 4 times for example, this magnitude could grow. There could be justification that there is enough methods that use the different initialize and hence it is not required for each case to set the value it wants(code replication), but when the software grows it adds more problem.
The better way to go is, have a method with no parameters and have another one that takes an object which is composed of all the parameters.
create a class and put all the settings parameter in one.
public class AllSettings
{
Public layer A
{
get{return a;};
set{this.a = value;}
}
public network B
{
//
}
public InitialSettings
{
get
{
if(A == Null)
{
A = defaultValue;
}
//so with B and C
return settings; //Has all the initial settings required.
}
}
}
By doing the above, you get to choose if you want to initialize part of the object or not by using the set properties. And a final check is done for NULL, before the actual initial settings are created. If it is null put some default value, if not fine.
So in this case if a new parameter pops up later in development, it is as good as adding a new property and setting the default value. Existing cases need not worry about that and the new ones can override the default with the set in the property.
I have heard this comment too, do i have to create a class for this? Is it not costly? Well we have evolved now in the managed world where you do not worry about the object creation and deletion. Also some debate on the style cop issues, where you have to create only one class per file, this is debatable but since it is a different topic; I will leave it aside for now.
For better design in .NET, please refer to Framework Design Guidelines (useful links below). The design guidelines states the above scenario in a different way. Though the design guidelines book states the above scenario to be handled in a different way, the change I have indicated is an acceptable and agreeable design style!
URLs:
PDC talk by authors.
The link to the book.
Note: All the code examples are based on C# programming language.
As every statement needs a justification, let's see the scenario:
I have a protocol that takes n parameters, in order for a consumer to run his test case he would need to set up some parameters as an initial condition.
say there are 3 parameters for simplicity, a, b, c.
public settings Initialize();
public settings Initialize(a,b);
public settings Initialize(b,c);
public settings Initialize(a,c);
...
In a real world obviously the parameters could grow in size. So what happens when a 4th parameter is added say d. You have to write overloaded methods encompassing the different combinations. so it becomes 3 X 4 times for example, this magnitude could grow. There could be justification that there is enough methods that use the different initialize and hence it is not required for each case to set the value it wants(code replication), but when the software grows it adds more problem.
The better way to go is, have a method with no parameters and have another one that takes an object which is composed of all the parameters.
create a class and put all the settings parameter in one.
public class AllSettings
{
Public layer A
{
get{return a;};
set{this.a = value;}
}
public network B
{
//
}
public InitialSettings
{
get
{
if(A == Null)
{
A = defaultValue;
}
//so with B and C
return settings; //Has all the initial settings required.
}
}
}
By doing the above, you get to choose if you want to initialize part of the object or not by using the set properties. And a final check is done for NULL, before the actual initial settings are created. If it is null put some default value, if not fine.
So in this case if a new parameter pops up later in development, it is as good as adding a new property and setting the default value. Existing cases need not worry about that and the new ones can override the default with the set in the property.
I have heard this comment too, do i have to create a class for this? Is it not costly? Well we have evolved now in the managed world where you do not worry about the object creation and deletion. Also some debate on the style cop issues, where you have to create only one class per file, this is debatable but since it is a different topic; I will leave it aside for now.
For better design in .NET, please refer to Framework Design Guidelines (useful links below). The design guidelines states the above scenario in a different way. Though the design guidelines book states the above scenario to be handled in a different way, the change I have indicated is an acceptable and agreeable design style!
URLs:
PDC talk by authors.
The link to the book.
Note: All the code examples are based on C# programming language.
Thursday, October 30, 2008
Levels of programming, based on design principles.
Just a small writeup based on the programming design style, that I commonly come across with various programmers.
To give some context, let's take an example of creating an object called car (automobile).
Level 0 programmers are those who think, writing more common code is better and generalize them in to static methods that take numerous parameters.
public static void CreateACar(Engine engine, Color color)
{
//rest of the code here;
};
The problem is if the car needs to be created with a new property like sedan/coupe, then a new parameter needs to be added and this keeps growing. If the arguments grow then they add a structure to encompass all these arguments and pass them.
The next level of programmers are those who treat each of attribute of the object as it's property and create a class like the below:
class Car : IAuto
{
private Color color;
private Engine engine;
public Engine Engine
{
get
{
return this.engine;
}
set
{
this.engine = value;
}
}
Public IAuto CreateACar()
{
//rest of the code;
}
}
The above code works great, even if there are new parameters to be added. It is as simple as adding new properties and verifying them before creating the car. But some assumptions have to be made, say this car runs on a "road" and the car creation assumes the road to be some type (could be Enum) and ties the object to it. What if the road's condition changes and a car that code run while creation cannot run all the time on the road. Some cases/scenarios while creating the car is missing and it does not cover all the situations. This is what happens when the object is strongly tied and has lot of properties.
The next level of programmers are for making functionalities atomic with individual classes and then tying them together based on the scenarios or rules. The rules defines what goes in creating the car object.
say it could be class Road, class Car, Interface IAuto etc.
Looks like more classes that has smaller functionality. Yes, exactly these are all small dumb classes and are atomic. But when combined with the rules and scenarios that change time and again, they come in handy as they are very flexible and requires less change.
Take the .NET library, it exactly fits the last design model discussed, more dumb classes combined together giving a great flexibility and power for creating more applications.
This is a followup of my initial design post - http://globalhandler.blogspot.com/2007/05/software-design-goals-and-philosophies.html
To give some context, let's take an example of creating an object called car (automobile).
Level 0 programmers are those who think, writing more common code is better and generalize them in to static methods that take numerous parameters.
public static void CreateACar(Engine engine, Color color)
{
//rest of the code here;
};
The problem is if the car needs to be created with a new property like sedan/coupe, then a new parameter needs to be added and this keeps growing. If the arguments grow then they add a structure to encompass all these arguments and pass them.
The next level of programmers are those who treat each of attribute of the object as it's property and create a class like the below:
class Car : IAuto
{
private Color color;
private Engine engine;
public Engine Engine
{
get
{
return this.engine;
}
set
{
this.engine = value;
}
}
Public IAuto CreateACar()
{
//rest of the code;
}
}
The above code works great, even if there are new parameters to be added. It is as simple as adding new properties and verifying them before creating the car. But some assumptions have to be made, say this car runs on a "road" and the car creation assumes the road to be some type (could be Enum) and ties the object to it. What if the road's condition changes and a car that code run while creation cannot run all the time on the road. Some cases/scenarios while creating the car is missing and it does not cover all the situations. This is what happens when the object is strongly tied and has lot of properties.
The next level of programmers are for making functionalities atomic with individual classes and then tying them together based on the scenarios or rules. The rules defines what goes in creating the car object.
say it could be class Road, class Car, Interface IAuto etc.
Looks like more classes that has smaller functionality. Yes, exactly these are all small dumb classes and are atomic. But when combined with the rules and scenarios that change time and again, they come in handy as they are very flexible and requires less change.
Take the .NET library, it exactly fits the last design model discussed, more dumb classes combined together giving a great flexibility and power for creating more applications.
This is a followup of my initial design post - http://globalhandler.blogspot.com/2007/05/software-design-goals-and-philosophies.html
Saturday, September 22, 2007
.NET remoting – speed / security
.NET remoting is a guaranteed mechanism of talking between multiple objects in different appdomain. What is appdomain? If you know the difference between managed world and un-managed world then you should have come across appdomains. CLR when started (it will start when the application is being run) will occupy a section of the un-managed memory (we call it un-managed because the developer is responsible for creation and deletion) and makes a section with in it, managed memory. Hence forth whatever objects are being created in the application is run within the managed segment of memory and the whole boundary is termed as appdomain or application domain.
Using remoting the various appdomains can interact/exchange data; this could be in the same machine or machine to machine across firewalls etc.
The design of the remoting could be such that of a client server model. Say if you are designing the provider with interfaces so that their implementation will be inheriting MarshalByRefObject and hence the clients/consumer (which sits in other appdomains) can access the data using the activator methods. There could be some potential issues with respect to security if you expose the interfaces directly, say in my case I have the consumer and the provider sitting in the same machine. And the provider uses certain DLL’s to play with the data. The consumer should be restricted with the data access the provider defines the scope of the data for the consumers, in this case if the provider exposes the interfaces, which could be re-casted.
And also when the interfaces implementation directly inherits MarshalByRefObject then what happens is the consumer gets the actual object each time, this means each time you need to pull a data your request and the connection is going to be really slow, can I overcome it, yes ask for more data at one shot. Dough well I do not know when I have to ask data, say the server/provider gives the data, there will be events raised and you will be monitoring the events and have the data flow back and forth. So in this case what to do?
Yep you got to think of a dataset (ADO.NET) kind off model, pass a duplicate copy each time and let that be a structure (at least in my case) so that all the data that are changed and needs to be shown in the GUI or front end is got as one shot. What happens constantly if the server/provider’s data is changing queue some data wait for some time and then re-send the structure each time, by this mechanism you have the duplicate copy each time. What does that mean? Well when some is taking the actual copy then you are asking the main provider to wait until the consumer is done with the object/data. So you are essentially ending up in a synchronous scenario, has any design be considered a good one if it is synchronous only in normal scenario? We know the answer it is NO, so we have to do it the above way to make it asynchronous. Who ever gets the data or has will not trouble the other. And by doing this we save the multiple clients requests that are waiting to be answered by the provider.
How did we end up like the above design?, what happened was the consumer/provider access model made the whole application slog, just to get a single data and this happened more often when more data is passed. So the pipes have been heavily used and the operation was slow. Though the advantage is we have a thread safe code, but total impact was slow. And the irony was my application is called Extreme tuning utility that means faster performance of the hardware based on the algorithms we run, can this itself ruin the machine’s speed…no ways….So we need to think of faster mechanism as described above. And also not allowing the hackers to interpret the interfaces the way they wanted, remember the re-casting stuff I started in the beginning.
Using remoting the various appdomains can interact/exchange data; this could be in the same machine or machine to machine across firewalls etc.
The design of the remoting could be such that of a client server model. Say if you are designing the provider with interfaces so that their implementation will be inheriting MarshalByRefObject and hence the clients/consumer (which sits in other appdomains) can access the data using the activator methods. There could be some potential issues with respect to security if you expose the interfaces directly, say in my case I have the consumer and the provider sitting in the same machine. And the provider uses certain DLL’s to play with the data. The consumer should be restricted with the data access the provider defines the scope of the data for the consumers, in this case if the provider exposes the interfaces, which could be re-casted.
And also when the interfaces implementation directly inherits MarshalByRefObject then what happens is the consumer gets the actual object each time, this means each time you need to pull a data your request and the connection is going to be really slow, can I overcome it, yes ask for more data at one shot. Dough well I do not know when I have to ask data, say the server/provider gives the data, there will be events raised and you will be monitoring the events and have the data flow back and forth. So in this case what to do?
Yep you got to think of a dataset (ADO.NET) kind off model, pass a duplicate copy each time and let that be a structure (at least in my case) so that all the data that are changed and needs to be shown in the GUI or front end is got as one shot. What happens constantly if the server/provider’s data is changing queue some data wait for some time and then re-send the structure each time, by this mechanism you have the duplicate copy each time. What does that mean? Well when some is taking the actual copy then you are asking the main provider to wait until the consumer is done with the object/data. So you are essentially ending up in a synchronous scenario, has any design be considered a good one if it is synchronous only in normal scenario? We know the answer it is NO, so we have to do it the above way to make it asynchronous. Who ever gets the data or has will not trouble the other. And by doing this we save the multiple clients requests that are waiting to be answered by the provider.
How did we end up like the above design?, what happened was the consumer/provider access model made the whole application slog, just to get a single data and this happened more often when more data is passed. So the pipes have been heavily used and the operation was slow. Though the advantage is we have a thread safe code, but total impact was slow. And the irony was my application is called Extreme tuning utility that means faster performance of the hardware based on the algorithms we run, can this itself ruin the machine’s speed…no ways….So we need to think of faster mechanism as described above. And also not allowing the hackers to interpret the interfaces the way they wanted, remember the re-casting stuff I started in the beginning.
Friday, September 21, 2007
Interfaces Vs Classes
Are you a programmer with decent experience and are you in to .NET then you wouldn't have missed this question interfaces Vs classes. you must have come across this when you do design, or if not at least when you are interviewing. This happens to be one of the very favorite questions among the interviewers.
Initially I had different ways of understanding things and ended up giving different answers based on different reasons. Then I sat down with my senior (Nelson Kidd) in my current work place to understand what the real deal between both is. The below write-up is based on his teaching/inputs to me, a lot is based on our project but still it is very generic and applies to all.
Below you will see more than the common differences like the abstract classes can have implementations but the interfaces cannot, classes have the classes’ typical properties.
Interfaces are the way to mention the contract behavior, where as with classes it is hard to maintain it is like if you are providing API’s and if you are the provider of the API, if you are using interfaces you say it is like these are the behavior and properties. If you are doing the same by the way of classes (all the way inheriting with different provider side implementations) then it is like saying well this is the behavior and properties and also this is the way I am going to implement it. Then when something changes in the API’s end it becomes way to harder if the provider API’s are built based on classes, the consumers need to change the way their code is written. But if it is interface there will be very minimal impact or none in terms of addition of new methods to the interface and it will be a minor impact if something changes/removed. The killer here is the difference in the way the classes has to be inherited to achieve different implementation.
Dough I am not a C# programmer and my code is in C++, then what’s the deal, so you would create various Abstract classes with various pure virtual functions and the classes will implement the methods of the abstract classes. With classes there is a lot of way of messing out with the security/access specifier, that you can use public/private/protected. And you need to develop a document for the API users to understand when a method can be called, what is the context blah blah…so that they can understand how to use your classes.
But the nicer way with interface is that there is no way to get it wrong, I mean by mistake when using classes developers can misuse the access specifier and hence gets things wrong. But with interfaces they are the way they are and the .NET platform will not allow you to mess up with the interfaces, because it works straight things that are allowed are allowed and things that are not are not.
Think from a business angle it all boils down to the contract agreement, when you are developing enterprise wide applications you are often providing some API’s and the contract is signed for that. These API’s are easier to define on the first hand by understanding the requirements without bothering the implementation we can define whole lot of interfaces to it in the first place. So it is using interfaces helps in bridging the gap between requirements and development. The second thing is you do not have the luxury of asking your fellow customers/cross-company developers to change their code it is because you designed the API’s using the classes.
A simple way is to use a factory pattern to give the instance of the implementation of the interface and the caller will be just asking for the interface’s instances. But if the same where a class then there will be many strict design required as opposed to being very informal to the interface implementations and of course multiple interfaces could be implemented. Interfaces be re-casted, hence for security issues on the end (like .NET remoting) use classes, at least wrap the interfaces that you want to expose with the classes wrapping it.
There are different kinds off programmers, some would say this is how you have to do it, and some totally do not care about it unless the end result is fine. The rules are to be broken, but understand when and where you can break, understand the whole problem and give the best solution in terms of your approach and the way you attack, remember some one is paying for you and as long as they see the value in the way you do it, then you are in the right direction; if not it is time to THINK.
Initially I had different ways of understanding things and ended up giving different answers based on different reasons. Then I sat down with my senior (Nelson Kidd) in my current work place to understand what the real deal between both is. The below write-up is based on his teaching/inputs to me, a lot is based on our project but still it is very generic and applies to all.
Below you will see more than the common differences like the abstract classes can have implementations but the interfaces cannot, classes have the classes’ typical properties.
Interfaces are the way to mention the contract behavior, where as with classes it is hard to maintain it is like if you are providing API’s and if you are the provider of the API, if you are using interfaces you say it is like these are the behavior and properties. If you are doing the same by the way of classes (all the way inheriting with different provider side implementations) then it is like saying well this is the behavior and properties and also this is the way I am going to implement it. Then when something changes in the API’s end it becomes way to harder if the provider API’s are built based on classes, the consumers need to change the way their code is written. But if it is interface there will be very minimal impact or none in terms of addition of new methods to the interface and it will be a minor impact if something changes/removed. The killer here is the difference in the way the classes has to be inherited to achieve different implementation.
Dough I am not a C# programmer and my code is in C++, then what’s the deal, so you would create various Abstract classes with various pure virtual functions and the classes will implement the methods of the abstract classes. With classes there is a lot of way of messing out with the security/access specifier, that you can use public/private/protected. And you need to develop a document for the API users to understand when a method can be called, what is the context blah blah…so that they can understand how to use your classes.
But the nicer way with interface is that there is no way to get it wrong, I mean by mistake when using classes developers can misuse the access specifier and hence gets things wrong. But with interfaces they are the way they are and the .NET platform will not allow you to mess up with the interfaces, because it works straight things that are allowed are allowed and things that are not are not.
Think from a business angle it all boils down to the contract agreement, when you are developing enterprise wide applications you are often providing some API’s and the contract is signed for that. These API’s are easier to define on the first hand by understanding the requirements without bothering the implementation we can define whole lot of interfaces to it in the first place. So it is using interfaces helps in bridging the gap between requirements and development. The second thing is you do not have the luxury of asking your fellow customers/cross-company developers to change their code it is because you designed the API’s using the classes.
A simple way is to use a factory pattern to give the instance of the implementation of the interface and the caller will be just asking for the interface’s instances. But if the same where a class then there will be many strict design required as opposed to being very informal to the interface implementations and of course multiple interfaces could be implemented. Interfaces be re-casted, hence for security issues on the end (like .NET remoting) use classes, at least wrap the interfaces that you want to expose with the classes wrapping it.
There are different kinds off programmers, some would say this is how you have to do it, and some totally do not care about it unless the end result is fine. The rules are to be broken, but understand when and where you can break, understand the whole problem and give the best solution in terms of your approach and the way you attack, remember some one is paying for you and as long as they see the value in the way you do it, then you are in the right direction; if not it is time to THINK.
Saturday, September 08, 2007
Asynchronous delegates in .NET
Delegates - Delegates are type safe function pointers that are usually used as a enabler of call back mechanism. Delegates are synchronous by default in the .NET environment. Which means when an event is fired and a delegate is invoked, the delegate is completed synchronously. This could be made asynchronous too, but why?
Say for example in my case I have a .NET remoted server which could be connected by various clients and each client that is connecting could send requests and get a response back from the server. So what happens if an event in the server has its subscriptions in the client side, say there are three subscriptions. We know that in a multiple subscription scenario the invocation goes from the first subscriber until the next in a sequential order. And what if an exception gets thrown while in the middle of executing the subscriber's procedure? The others in the subscription list have to wait until the exception is being handled. In this case we would want to make the mechanism asynchronous providing control to the server so that the other clients who are in the queue of being serviced will not be waiting for ever.
Asynchronous delegate
Say for example in my case I have a .NET remoted server which could be connected by various clients and each client that is connecting could send requests and get a response back from the server. So what happens if an event in the server has its subscriptions in the client side, say there are three subscriptions. We know that in a multiple subscription scenario the invocation goes from the first subscriber until the next in a sequential order. And what if an exception gets thrown while in the middle of executing the subscriber's procedure? The others in the subscription list have to wait until the exception is being handled. In this case we would want to make the mechanism asynchronous providing control to the server so that the other clients who are in the queue of being serviced will not be waiting for ever.
Asynchronous delegate
Thursday, June 28, 2007
Pay attention while you design dot NET Remoting running via a Windows Service
Aaah, I am having hard time nailing down issues, when a windows service is running my remoted server. The client could not connect to the server. Tried different forums including MSDN forums and could not find out whats going on. May be I did not understand the whole concept properly. So all i wanted to say is pay more attention while you wanted some kind of design like this. This is killing me !!!
Initially I had a remoted server using a remoting infrastructure and the client is able to connect, everything is fine. But when the remoted server and the remoting infrastructure are wrapped inside a Windows service, I could not get things working. The client disappoints me by not connecting and throws .NET remoting exceptions. OK to brief on remoting, we might have heard about the good old (D)COM this is now upgraded significantly and made easier with .NET framework, though .NET 1.1 had issues (lot of them) the framework beginning with .NET 2.0 (take a look @ .NET framework - click here) major issues has been resolved. Essentially remoting allows you to talk to objects beyond the boundaries such as application domains/process boundaries, be it the server is running in the same machine or different.
Remoting channels, usually in the form of HTTP, Binary format and IPC. MarshalByRefObject - objects that are derived from this base class complies with remoting, basically they could be remoted. Now remoting infrastructure provides you various ways of using the remoted objects singleton, reference etc.
Now coming to windows Service, there are lots of things you can do by using the windows service. A service is basically a background process, (Go to command prompt, type services.msc, you can get a display of all the services that are listed) which could do several tasks in the background. Why would you want to go for a service, say in my case I wanted to allow multiple clients to connect to my service (which runs the remoted server), do some custom actions when windows starts/shut down/reboot, make such that on Vista ,we could create gadgets and deploy them based on this service. The service could be started, stopped, paused and also the service installation could be based on various security levels whether to be installed for a user/admin/local system. Remember you have to provide impersonation level appropriately to make it run by the desired user groups.
Initially I had a remoted server using a remoting infrastructure and the client is able to connect, everything is fine. But when the remoted server and the remoting infrastructure are wrapped inside a Windows service, I could not get things working. The client disappoints me by not connecting and throws .NET remoting exceptions. OK to brief on remoting, we might have heard about the good old (D)COM this is now upgraded significantly and made easier with .NET framework, though .NET 1.1 had issues (lot of them) the framework beginning with .NET 2.0 (take a look @ .NET framework - click here) major issues has been resolved. Essentially remoting allows you to talk to objects beyond the boundaries such as application domains/process boundaries, be it the server is running in the same machine or different.
Remoting channels, usually in the form of HTTP, Binary format and IPC. MarshalByRefObject - objects that are derived from this base class complies with remoting, basically they could be remoted. Now remoting infrastructure provides you various ways of using the remoted objects singleton, reference etc.
Now coming to windows Service, there are lots of things you can do by using the windows service. A service is basically a background process, (Go to command prompt, type services.msc, you can get a display of all the services that are listed) which could do several tasks in the background. Why would you want to go for a service, say in my case I wanted to allow multiple clients to connect to my service (which runs the remoted server), do some custom actions when windows starts/shut down/reboot, make such that on Vista ,we could create gadgets and deploy them based on this service. The service could be started, stopped, paused and also the service installation could be based on various security levels whether to be installed for a user/admin/local system. Remember you have to provide impersonation level appropriately to make it run by the desired user groups.
Tuesday, June 26, 2007
WMI
Windows Management Instrumentation provides API's for retrieving system data and doing many hardware operations.
WMI Creator - This creates the essential code for what ever WMI data you wanted to collect. There are SQL queries for WMI called as WQL.
Following is a sample code to parse the SMBIOS data, by which you can collect the information on memory that your motherboard has. Instead of getting data via Windows, you can collect it through this interface. Well, why such a round about way of collecting data?
Yup in certain application development that needs more information on the hardware data, which usually the windows OS does not explicitly provide.
If you take a look @ SMBIOS spec, you will know how vast the structures are...
sample code
const string m_WmiNamespaceInterested = "ROOT\\WMI";
const string m_WqlQueryInterested = "select * from MSSMBios_RawSMBiosTables";
const string m_PropertyInterested = "SMBiosData";
internal void GetRawSmbiosData(out byte [] rawSmbiosDataArray)
{
object rawSMBiosData = null;
//Connection credentials to the remote computer - not needed if the logged in account has access
ConnectionOptions oConn = new ConnectionOptions();
ManagementScope oMs = new ManagementScope(m_WmiNamespace, oConn);
//get Fixed disk stats
ObjectQuery oQuery = new ObjectQuery(m_WqlQuery);
ManagementObjectSearcher oSearcher = new ManagementObjectSearcher(oMs, oQuery);
ManagementObjectCollection oReturnCollection = oSearcher.Get();
foreach (ManagementObject oReturn in oReturnCollection)
{
rawSMBiosData = oReturn[m_PropertyInOutput];
}
rawSmbiosDataArray = rawSMBiosData as byte[];
}
WMI Creator - This creates the essential code for what ever WMI data you wanted to collect. There are SQL queries for WMI called as WQL.
Following is a sample code to parse the SMBIOS data, by which you can collect the information on memory that your motherboard has. Instead of getting data via Windows, you can collect it through this interface. Well, why such a round about way of collecting data?
Yup in certain application development that needs more information on the hardware data, which usually the windows OS does not explicitly provide.
If you take a look @ SMBIOS spec, you will know how vast the structures are...
sample code
const string m_WmiNamespaceInterested = "ROOT\\WMI";
const string m_WqlQueryInterested = "select * from MSSMBios_RawSMBiosTables";
const string m_PropertyInterested = "SMBiosData";
internal void GetRawSmbiosData(out byte [] rawSmbiosDataArray)
{
object rawSMBiosData = null;
//Connection credentials to the remote computer - not needed if the logged in account has access
ConnectionOptions oConn = new ConnectionOptions();
ManagementScope oMs = new ManagementScope(m_WmiNamespace, oConn);
//get Fixed disk stats
ObjectQuery oQuery = new ObjectQuery(m_WqlQuery);
ManagementObjectSearcher oSearcher = new ManagementObjectSearcher(oMs, oQuery);
ManagementObjectCollection oReturnCollection = oSearcher.Get();
foreach (ManagementObject oReturn in oReturnCollection)
{
rawSMBiosData = oReturn[m_PropertyInOutput];
}
rawSmbiosDataArray = rawSMBiosData as byte[];
}
Saturday, May 19, 2007
Tuesday, May 15, 2007
Agile software development & Extreme Programming XP
Recently I came across this new terminology Agile Software Development; this is what I learnt
In general, let me take an example to co-relate.
If you have heard of the 20-20 cricket match, then you know that the strategies for playing a 20-20 match is different from that of a normal 50 over match. The same applies here, but instead of having just one 20-20, the overall development process is split in to multiple pieces of software development. To add more, there are multiple iterations of the software development process focusing on delivering a package out of all iteration. It is kind off a fast paced development environment.
Read more @ wikipedia -> Agile software development
Ok let’s go to the extreme programming model now
Involving collaboration in the software development process, this works based on a feedback (like the feedback circuitry) mechanism to stay on track. This also provides a simple for planning and tracking the software development.
Extreme programming
Read more @ wikipedia -> extreme programming
Extreme programmers, if you happen to read this, please leave your comments on how this model is useful and what benefits did you achieve?
In general, let me take an example to co-relate.
If you have heard of the 20-20 cricket match, then you know that the strategies for playing a 20-20 match is different from that of a normal 50 over match. The same applies here, but instead of having just one 20-20, the overall development process is split in to multiple pieces of software development. To add more, there are multiple iterations of the software development process focusing on delivering a package out of all iteration. It is kind off a fast paced development environment.
Read more @ wikipedia -> Agile software development
Ok let’s go to the extreme programming model now
Involving collaboration in the software development process, this works based on a feedback (like the feedback circuitry) mechanism to stay on track. This also provides a simple for planning and tracking the software development.
Extreme programming
Read more @ wikipedia -> extreme programming
Extreme programmers, if you happen to read this, please leave your comments on how this model is useful and what benefits did you achieve?
Thursday, May 10, 2007
Software design goals and philosophies….
“Every extra week spent in making a good design will always be paid off “
What is a good design?
There are no definite metrics to judge a software design to determine the degree of how good it is.
Though there are ways to see if they stick to some common guidelines and methodologies.
1.Define problem from the software consumer perspective – Say for example there is another developer who will use your design/code, end user or for that matter any one.
2.Does the proposal address the problem statement
3.RED flag design issues, these are not necessarily mandatory, but definitely we must pay attention to.
a. Near neighbor dependencies
b. Wise use of asynchronous design
i.Essentially not to block requests.
ii.In all possible ways this design should be implemented.
iii.But there is overhead in writing code.
4.Use of Has-A VS Is-A
•Inherit - Use same method implementation, this should be the type chosen only it makes a strong sense to use it, which means better to go for the aggregation model.
•Aggregate – Encapsulate lots of smaller classes.
•It also makes sense to make such an encapsulated class public so that others can use the same.
5.Develop more generalized code and it is better to have more dumb classes, when combined together makes a smart. The best example would be the .NET framework which is built over humongous amount of small classes, which makes the libraries much richer.
6.Make sure the transactions happening through different objects are framed correctly. If any circular pattern is found in the transaction model, then it is not a good design.
7.Make sure that there is no dependency on each layer.
8.Each transaction between the objects should contain parameters less than or equal to five to make it more simple and understanding.
9.C# vs. C++ code testing: There is not a different approach/angle of testing the C# code from C++.
What is a good design?
There are no definite metrics to judge a software design to determine the degree of how good it is.
Though there are ways to see if they stick to some common guidelines and methodologies.
1.Define problem from the software consumer perspective – Say for example there is another developer who will use your design/code, end user or for that matter any one.
2.Does the proposal address the problem statement
3.RED flag design issues, these are not necessarily mandatory, but definitely we must pay attention to.
a. Near neighbor dependencies
b. Wise use of asynchronous design
i.Essentially not to block requests.
ii.In all possible ways this design should be implemented.
iii.But there is overhead in writing code.
4.Use of Has-A VS Is-A
•Inherit - Use same method implementation, this should be the type chosen only it makes a strong sense to use it, which means better to go for the aggregation model.
•Aggregate – Encapsulate lots of smaller classes.
•It also makes sense to make such an encapsulated class public so that others can use the same.
5.Develop more generalized code and it is better to have more dumb classes, when combined together makes a smart. The best example would be the .NET framework which is built over humongous amount of small classes, which makes the libraries much richer.
6.Make sure the transactions happening through different objects are framed correctly. If any circular pattern is found in the transaction model, then it is not a good design.
7.Make sure that there is no dependency on each layer.
8.Each transaction between the objects should contain parameters less than or equal to five to make it more simple and understanding.
9.C# vs. C++ code testing: There is not a different approach/angle of testing the C# code from C++.
Subscribe to:
Posts (Atom)