Runtime Adaptation is the ability for an object to increase and grow into another type of object at runtime.
In most Object Oriented languages an object is "born" with a set of abilities. Typically this is done through inheritance or interfaces.
class JackOfAllTrades : IPerson, IHandyMan, IPlumber, IBrainSurgeon, IAutoMechanic
{
}
JackOfAllTrades can be used in any method where an IPerson, IHandyMan, IPlumber, IBrainSurgeon, or IAutoMechanic is needed.
At runtime JackOfAllTrades can not become IDentist. JackOfAllTrades can not learn to be a dentist and cannot act in the role of a dentist.
Runtime Adaptation allows JackOfAllTrades to become a full fledged dentist at runtime and retain this ability carrying forward. JackOfAllTrades does not have to use another object that implements IDentist and then have that object do work in his behalf.
Just as JackOfAllTrades wants to increase in ability JackOfAllTrades may want to loose abilities as well and give up plumbing.
The acquisition of new abilities could be considered "Behavior as a Service" and I could vend the IDentist capabilities to your JackOfAllTrades.
Just a small glimpse of the sandbox in which my mind plays.
Thursday, March 26, 2009
Tuesday, March 17, 2009
Design by Use to the rescue... AGAIN
Just a quick note. Yesterday I was bogged down in a serious piece of code re-work. It was the changing of part of a framework. Since it is a framework, everything built on it is affected by change.
I was changing from an Event based model to what I term a "usage" based model. Remembering the advice of Stroustrup that resource acquisition is allocation I used this knowledge to begin to make the changes. I became stuck very quickly. Stuck in the overwhelming amount of code and all of the many classes that had overridden these framework interfaces.
Once again I remembered, Design by Use. When I did this the paralysis ended and the solution began flowing. I started at the level from which the new model/framework would be called and I wrote the code as if the new framework already existed. Often the old code was harvested into the new methods where appropriate. Everything flowed and it was more like writing new code with no dependencies than re-working code. Why? Because that is what it became, new code!
All of you must try Design by Use! It has really made a difference for me. When ever you are stuck try it out!
I was changing from an Event based model to what I term a "usage" based model. Remembering the advice of Stroustrup that resource acquisition is allocation I used this knowledge to begin to make the changes. I became stuck very quickly. Stuck in the overwhelming amount of code and all of the many classes that had overridden these framework interfaces.
Once again I remembered, Design by Use. When I did this the paralysis ended and the solution began flowing. I started at the level from which the new model/framework would be called and I wrote the code as if the new framework already existed. Often the old code was harvested into the new methods where appropriate. Everything flowed and it was more like writing new code with no dependencies than re-working code. Why? Because that is what it became, new code!
All of you must try Design by Use! It has really made a difference for me. When ever you are stuck try it out!
Monday, March 16, 2009
Solutions and Opinions
Applying my knowledge of Computer Science and recalling experiences from years of application I find myself contemplating "solutions" and "opinions".
When I am writing code, when I am actually typing in the code, I am working towards a solution to a problem.
These problems are constrained to be solved in the environment in which they exist. For instance the code has to be in C#, it has to work in Windows Forms, etc. There are other constraints such as memory usage, and performance. And still there are constraints in how the code will present itself to the user through the User Interface. The User Interface is constrained by accepted and common interactions defined by the domain of the product. What I mean is a Word Processor has a certain set of UI expectations and constraints placed on it by the user community just because it is a word processor.
Solving problems as a developer is a difficult task. The breadth and depth of knowledge and experience must be large and ever increasing. I have seen many people never gain enough knowledge and experience necessary to continue to advance as a software developer. Some of these people were aware of their situation and made appropriate career choices. Others were oblivious to their position and found themselves locked into dead end tasks or even fired.
Currently I find myself re-working some code. The code came into existence because of a short coming in the design. The code was the results of considering what would be the simplest thing to do while fitting into the current design. As with all code once it is wrote it becomes part of the environment in which any new code will exist and has influence over how the new code will be implemented.
Honestly my head seems to hurt at the thought of re-working the code so that current needs for improved resource usage can be realized.
The burden of the solution rests upon me. The idea of sharing the problem with others and getting their opinion on how to develop the solution is interesting and maybe even therapeutic but ultimately shallow. In all of my years of experience I have never seen anything more than a superficial "pre-flight" check from having others review a design that is based upon a large set of code that the reviewers have no real knowledge of the inner workings, couplings, code-arounds, and all the other things that make up that piece of working code. If the code had a boundary with some other system then it would be beneficial to talk to the owners of the other systems. This current problem is completely encapsulated in "my" code.
As I sit here focused on the problem at hand a tinge of jealousy seems to rise up. Jealousy of what you ask? Jealousy of those around me working on things where opinion is sufficient and no further effort is required.
The solution I have to invent has to meet those many constraints I mentioned before. It will be domonstrable that I have met the requirements through running the profilers and passing the programmer's tests. I literaly sit at this desk for hours without end and yes it is hard.
So, I am a bit jealous today of the buzz I hear going on around me where people are making decisions based on opinions and where people can declare "It must be done like this" on one day and then the next day say "It now must be done differently" and those that actually have to "do the doing" are different people. Do they feel more important? Do they feel more job satisfaction? Do they feel less pressure? Do they have the burden of constantly improving? Do they have the burden of constantly replacing the core tools of their trade with new and shiny tools that are completely incompatible with the old tools and basically no better (i.e. Fortan -> Pascal -> Modula 2 -> Ada -> C -> C++ -> Java -> C#). I am absolutely sure I could have created the current product that I am working on using Structured Analysis and C and it would be just as good as the one we have now that uses Object Oriented Design and C#.
So, I sit here, improving the resource utilitization of the product and I wonder what difference does it all make. Someone else in the product could be making a choice right now that uses all of the RAM I am trying to save. Somewhere someone is making yet another GUI toolkit to which I will have to eventually port the current system.
Oh yeah, I remember my motivation. A pay check. Yep that must be it. Because it surely is not all of the opinions I hear every day and change with the current weather.
When I am writing code, when I am actually typing in the code, I am working towards a solution to a problem.
These problems are constrained to be solved in the environment in which they exist. For instance the code has to be in C#, it has to work in Windows Forms, etc. There are other constraints such as memory usage, and performance. And still there are constraints in how the code will present itself to the user through the User Interface. The User Interface is constrained by accepted and common interactions defined by the domain of the product. What I mean is a Word Processor has a certain set of UI expectations and constraints placed on it by the user community just because it is a word processor.
Solving problems as a developer is a difficult task. The breadth and depth of knowledge and experience must be large and ever increasing. I have seen many people never gain enough knowledge and experience necessary to continue to advance as a software developer. Some of these people were aware of their situation and made appropriate career choices. Others were oblivious to their position and found themselves locked into dead end tasks or even fired.
Currently I find myself re-working some code. The code came into existence because of a short coming in the design. The code was the results of considering what would be the simplest thing to do while fitting into the current design. As with all code once it is wrote it becomes part of the environment in which any new code will exist and has influence over how the new code will be implemented.
Honestly my head seems to hurt at the thought of re-working the code so that current needs for improved resource usage can be realized.
The burden of the solution rests upon me. The idea of sharing the problem with others and getting their opinion on how to develop the solution is interesting and maybe even therapeutic but ultimately shallow. In all of my years of experience I have never seen anything more than a superficial "pre-flight" check from having others review a design that is based upon a large set of code that the reviewers have no real knowledge of the inner workings, couplings, code-arounds, and all the other things that make up that piece of working code. If the code had a boundary with some other system then it would be beneficial to talk to the owners of the other systems. This current problem is completely encapsulated in "my" code.
As I sit here focused on the problem at hand a tinge of jealousy seems to rise up. Jealousy of what you ask? Jealousy of those around me working on things where opinion is sufficient and no further effort is required.
The solution I have to invent has to meet those many constraints I mentioned before. It will be domonstrable that I have met the requirements through running the profilers and passing the programmer's tests. I literaly sit at this desk for hours without end and yes it is hard.
So, I am a bit jealous today of the buzz I hear going on around me where people are making decisions based on opinions and where people can declare "It must be done like this" on one day and then the next day say "It now must be done differently" and those that actually have to "do the doing" are different people. Do they feel more important? Do they feel more job satisfaction? Do they feel less pressure? Do they have the burden of constantly improving? Do they have the burden of constantly replacing the core tools of their trade with new and shiny tools that are completely incompatible with the old tools and basically no better (i.e. Fortan -> Pascal -> Modula 2 -> Ada -> C -> C++ -> Java -> C#). I am absolutely sure I could have created the current product that I am working on using Structured Analysis and C and it would be just as good as the one we have now that uses Object Oriented Design and C#.
So, I sit here, improving the resource utilitization of the product and I wonder what difference does it all make. Someone else in the product could be making a choice right now that uses all of the RAM I am trying to save. Somewhere someone is making yet another GUI toolkit to which I will have to eventually port the current system.
Oh yeah, I remember my motivation. A pay check. Yep that must be it. Because it surely is not all of the opinions I hear every day and change with the current weather.
Subscribe to:
Posts (Atom)