Introduction
In the programming world, we have a large range of skills. One programmer may take a month to create a program, and another might be able to do the same application in a day. The first program may be full of bugs, and un-maintainable, while the 2nd is stable and easy to extend. In this series of articles, I will explore different facets of these facts. My objective is to provide you with tools you can use to improve your abilities as a software developer.
This first article deals with helping you evaluate how much you know of the basics - object-oriented programming and design. I'll do this by breaking down object oriented programming into 3 tiers. Hopefully, you will be able to find your own level within those tiers, and use that to find the next steps to improving your knowledge. Right then, on with the show....
The Program
I thought this would be easier to follow if we discussed it in terms of an imaginary program. My example that comes to mind is a simple form with a data grid, and a popup data entry form that is used to enter new data into the grid. Note that any code samples in this article are pseudo-code - there is no downloadable code for this article.
Rules
When you first learn the game of chess, you learn the rules. Pawns can move like that, and knights like that, and the game is over when the king is trapped - checkmate!
Programming is the same, in that the first thing you have to understand are the rules. In programming, this is the syntax, and the programming environment (e.g., Visual Studio). Once you know the rules, you can write a program. In terms of our example, someone who has just learned the rules would probably write the code something like this:
sub MyDataGrid_RowClicked()
Dim MyDataForm as new DataForm()
MyDataForm.ShowModally
end sub
sub MyFormSaveButton_Clicked
MyGridForm.DataGrid.RefreshData
Unload Me
end sub
The application will work. When a user clicks on the data row, then the data form will display. Once the data has been updated, then the grid will refresh.
Principles
Once you have learned the basic rules of chess, you start learning the principles. A queen is more valuable than a pawn. Knights and Bishops are roughly equal in value. Try and control the center of the board.
In programming, we have principles too. They are fairly well known, and have been for a while. Coupling, cohesion, use of functions...there are many more. Once you know the principles, your programs become "better". This means that they are easier to write, understand, and extend. They may scale better, and interface easier.
Once a programmer has learned some programming principles, they may recognize that the sample code in the previous section was flawed. MyGridForm and MyDataForm refer to each other. In object oriented terms, this is known as coupling, and it is bad because they are now dependant on each other. When one changes, it can cause problems in the other. Multiply by a thousand, and you have spaghetti code.
Armed with knowledge that coupling is bad, we may re-write the previous code as follows:
sub MyDataGrid_RowClicked()
Dim MyDataForm as new DataForm()
MyDataForm.CustomShowMethod(myRowData)
MyDataForm.ShowModally
MyDataGrid.Refresh
end sub
sub MyFormSaveButton_Clicked
Unload Me
end sub
This is superior to the previous version, because MyDataForm is no longer coupled to MyGridForm.
Patterns
If you want to succeed in chess competitions, you have to start studying. You study the games of the grandmasters, and you study the patterns of the opening moves. You study your own games, and you study the games of your peers and rivals.
In January 1995, almost 10 years ago, a group of four authors ganged together and published a book called Design Patterns. This book contains some of the knowledge of the programming grandmasters. They describe patterns as "simple and elegant solutions to specific problems in object oriented design". There are only 23 patterns in the book, but each summarizes years of hard-earned experience. In terms of concentrated knowledge per square inch of text, the book is very dense. (That's just my way of saying that it is not light reading material).
With new-found knowledge of patterns, we can revisit our application. Some of you may have noted that although MyDataForm is no longer coupled to MyGridForm, the reverse is not true. MyGridForm is still coupled to MyDataForm. With a little knowledge of patterns, we can remove that dependency.
abstract class FormCreator
function GetForm(rowData) as Form
end class
concrete class MyFormCreator
function GetForm() as Form
MyDataForm = new DataForm()
return MyDataForm
end sub
end class
sub MyDataGrid_RowClicked()
dim MyDataForm as Form = MyFormCreator.GetForm()
MyDataForm.CustomShowMethod(myRowData)
MyDataForm.ShowModally
MyDataGrid.Refresh
end subsub MyFormSaveButton_Clicked
Unload Me
end sub
The above is an implementation of the Factory Method pattern. I won't go into details, because that is not the point of the article. Suffice it to say, MyGridForm is no longer directly coupled to MyDataForm. If I wanted to, I could easily substitute another form MyOtherDataForm, without touching MyGridForm.
My Advice...
If you are learning the rules, then...
- Be aware that there are principles too.
- Understand that programming is not just about solving the problem at hand. There are consequences to the ways that you solve the problem. Try and be aware of that when you program.
- Understand that programming is not just about solving the problem at hand. Yes, I know I already said that. It's important, because that understanding is what will help you see the reasoning behind OO principles.
If you are learning to apply OO principles, then...
- Start by tackling one or two principles at a time; don't try to learn it all at once.
- Don't get caught up, or intimidated by the terms - encapsulation, inheritance, interface inheritance, coupling, cohesion, Liskov substitution principle, etc.
- Try to understand the reason for a principle. It can slow down development if you apply principles just for the sake of it, without understanding why. It can even lead to whole layers of your application that serve no real purpose. Once you understand the reasoning behind the principles, it becomes much easier to choose how and where to apply principles.
- The most important thing is that you try - the rest comes with experience. You will make mistakes, but your programs should still be superior to the ones you developed beforehand.
If you are learning patterns...
- Accept that you will never know them all. Some will be easier than others to pick up, and some you will never find a use for.
- Start by thinking of a particular challenge that you have, and then try and find a pattern that seems to help.
- Buy and read books on programming and design techniques. Try and expand your horizons.
- There are other patterns besides the original 23 - there are even some for business-domain specific stuff, such as accounting. Sometimes, it is worthwhile looking into those.
- Lastly, beware of overusing patterns - they can be overkill. Not every solution needs to be the most elegant and extensible one that you can devise.
Conclusion
Every developer has to be a designer as well. Even if you have someone who provides the broad brush-strokes of the application design, you still have to code the details. That said, if you never learn design patterns, you can still be a good programmer.
The same is not true of the principles. You absolutely need the principles to be able to design your own applications in such a way that they can survive the test of time. Experience has taught me that a medium to large program that is written without the use of principles will be re-written or scrapped. A small program that is written without applying OO principles will always stand on its own, and never integrate well with others.
For many of us, it's been a difficult (although exciting) few years picking up yet another language (C# or VB.NET or ASP.NET). We have to remember that there is more to it than just the language and the framework, and the latest technical how-to article.
There is such a huge wealth of knowledge available on the Internet, and in books (some of which are listed below). Enjoy.
References and Further Reading
Most of the references here relate to Principles and Patterns. For the rules, check your online help/SDK.
I believe the originator of the chess-programming analogy was Robert C Martin. I have not been able to find that reference though.
Article History
- 9 Jun 2004 - Altered introduction text.
- 14 June 2004 - Changed title, added some references, tweaked the intro and the conclusion based on feedback.
|
|
 |
 | My Dear Expert
negm_phlestin | 13:14 4 Apr '07 |
|
|
i want to ask you how to start learning object oriented
i tried to arrang it as follow :
1 :learn rules
2 :Princiles
3 :Patterns
4 :design ana analysis books
pleasec correct me
and there is something like Aspect oriented what your opinion about it
and when start to learn it
thank you
|
|
|
|
|
|
|
Buy a book and work through it, or just read some articles online on OO.
Your list is meaningless, what do you mean by principles ? Patterns are advanced, learn OO first.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
| Article Update
Steven Campbell | 19:15 14 Jun '04 |
|
|
Among some other minor tweaks, I changed the title. So apologies in advance to those who re-read it by mistake 
The old title was "How to become a Programming Master (Part 1)"  I think the title was misleading to some, annoying to others.
|
|
|
|
|
| Just a little precision
Franck Quintana | 14:50 7 Jun '04 |
|
|
I think that it would be cool if you can speak about the way of life of a good programmer.
In your opinion is it a special kind of person or just a person as many others?
Is it a pretentious person or a modest one?
Is it a person who sleeps 4 hours a night?
An excellent article that i've read is http://www.asp-php.net/tribune/programmite.php written by Redo (too bad it is only in french maybe u can translate it using google). It treats about the different levels of programming sick
it is a funny article but it is near the reality indeed.
|
|
|
|
|
|
|
Its a good thing that the article you reference is humerous - I don't think you can seriously categorize the personality or way of life of a good programmer, any more than you can categorize those in any other profession.
For fun, Google translated the points in the article you referenced as:
- The subject spends more time than envisaged on its computer to be programmed
- The subject neglects its other responsibilities (to leave the dustbins?. Yes, yes, one is there!)
- The subject multiplies the unfruitful attempts to take down its programming
- The subject encounters relational problems with all Item of the Collection Human
- The subject reads only books of more than 1000 pages to the red and/or black cover
- Does the subject carry its books where qu?il goes (car, voyages, train, plane, toilets, read?)
- The subject loses any temporal concept except time d?exécution of its procedures
- The subject holds of the incomprehensible conversations for the common run of people, however it uses terms present in any French dictionary.
I guess maybe some of those are true about me. The same could be said of any addictive activity though, such as online game playing - it does suck up more than its fair share of time.
|
|
|
|
|
| Interesting...
Colin Angus Mackay | 14:09 7 Jun '04 |
|
|
But I prefer the term "Developer". Programming is what I did in school. *
I think the difference between a "Programmer" and "Developer" is that the developer has more understanding, not only of the language and programming skills, but more understanding of how everything fits together, how everything is built up and how the application is going to fit into that structure, and if the structure doesn't exist how to get the proper foundations in place (either by building them, or by using the relevant tools).
A developer is someone who realises every day is an educational opportunity and will maximise that opportunity if time permits. They are someone who realises that they don't know everything about their domain, but will strive to ensure that they know exactly where to find out missing information when they happen across a gap in their knowledge.
On the other hand, many programmers will only learn something if they have to and generally they ask someone else first before thinking about how they may solve the problem themselves, or where the answer may be. By doing this they lose a great educational opportunity as they miss links to lots of related information on the way to the answer they currently seek. This means that a few months later when they are working on something related they ask again without thinking because they never built the foundations of their own knowledge.
* Then again, maybe I'm just being ultra picky.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
|
|
I've changed some of the semantics, since I know at least 1 other person that shares your opinions on this matter. Where there are 2, there are probably more...
|
|
|
|
|
| Congratulations!
Franck Quintana | 8:09 7 Jun '04 |
|
|
I found your article very interesting.
I think it is difficult to explain such a concept because it needs a relative experience to understand all you have understood.
If i have to criticize this article the only thing that i can say is: "can you try to define where the programming begins and where it ends".
When you talk about designs, imho it is more closer of the analyst job than the programer one.
Nice job indeed 
|
|
|
|
|
|
|
Thanks for the +ve feedback
Regarding "where programming ends, and design begins", I tried to touch on that point in the conclusion, where I said that you could still be a good programmer without knowing patterns.
In other words, I agree with you that patterns are primarily a design tool.
|
|
|
|
|
| Same old stuff ...
Sébastien Lorion | 7:26 7 Jun '04 |
|
|
I am becoming tired of that kind of articles (not just on this site). If you can't figure out how to learn by yourself, chances are you won't become a guru anytime soon.
What you highlight is not bad, but the real basis for excellence is : critical reading, analytical thinking, creative synthesis and attention to detail.
A good starting point about designing programs : How to Design Programs.
Best tool for a programmer : Google.
Sébastien
Intelligence shared is intelligence squared.
Homepage : http://sebastienlorion.com
|
|
|
|
|
|
|
I agree with your point on learning by yourself; however, I felt the need to write the article anyway...because I cannot imagine why a professional programmer would not want to learn more, and improve their abilities.
Its kindof pointless perhaps, because the people that might benefit from the article are not the people that hang around codeproject. Hence the silly title; to try and lure those who are maybe just on the site looking for help with simple programming problems.
The article is not as good as I'd hoped, but I'm expecting the next in the series to be a little more engaging, and perhaps less pompous
Anyway, thanks for the book link, and your feedback.
PS: Using FireFox browser, when I click on the .aspx links on your website homepage, it downloads the aspx page source.
|
|
|
|
|
|
|
Steven Campbell wrote:
I cannot imagine why a professional programmer would not want to learn more, and improve their abilities.
See my opinionated ramblings above for my view...
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
|
|
Oops! Pressed the submit button by accident. 
Steven Campbell wrote:
The article is not as good as I'd hoped, but I'm expecting the next in the series to be a little more engaging
I look forward to it.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
|
|
Thanks for pointing out aspx problem (and telling the whole world about it . I just got a new computer and I forgot to run "aspnet_regiis -i". It also remembered me to run iislockdown which is a wee bit more important.
Sébastien
Intelligence shared is intelligence squared.
Homepage : http://sebastienlorion.com
|
|
|
|
|
|
|
I love the quote in the banner on your website: "Intelligence shared is intelligence squared"
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
|
|
Colin Angus Mackay wrote:
I love the quote in the banner on your website: "Intelligence shared is intelligence squared"
Yea, and some of his jokes were really good too. Some even *gasp* rival mine.
Aaron Eldreth
TheCollective4.com
My Articles
While much is too strange to be believed,
Nothing is too strange to have happened.
- T. Hardy
|
|
|
|
|
|
|
Thanks If only more people would get that particular bit of wisdom ...
Sébastien
Intelligence shared is intelligence squared.
Homepage : http://sebastienlorion.com
|
|
|
|
|
| Missing stuff
Philip Fitzsimons | 4:37 7 Jun '04 |
|
|
some things that need covering:
RTFM - understand the language fully, even the stuff you don't think you will ever use.
Algorithms - patterns are very high level, you need to have a good idea of standard algorithms as they teach programmers how best to put code together.
Environment - all programs run in an environment, for example an OS (Unix/Windows) or a Sandbox, ApplicationDomain etc. If you know your environment you won't reinvent the wheel, and also understand where to start.
Coding Standards - variable naming, calling conventions, error handling, documentation: these are all things that you should standardise - it will safe time in writing code, and understanding stuff you wrote before.
Kiss - keep it simple stupid. Simple solutions are easier to write, maintain and fix.
Lateral - thinking laterally about problems. Most difficult problems don't need to be solved, see if there is an alternative way of doing something.
Read - look at other people's code, alot can be learnt from other people's style and solutions -see code project
Toolbox - build up a set of standard techniques that you can use and use again, keep the good snipets of code.
"When the only tool you have is a hammer, a sore thumb you will have."
|
|
|
|
|
|
|
I completely agree with you.
I want to add :
Low level : that is to say how the language work near the hardware (more practical to enhance your application performance)
|
|
|
|
|
|
|
I would classify RTFM, Environment, Coding Standards as Rules and Algorithms, Kiss, Lateral, Low Level as Principles.
To Read is a subset of the underlying message of the article - which is that you have to take it upon yourself to expand your knowledge.
Toolbox is less simple. In terms of software it is part of the rules (know your tools). In terms of code snippets, it touches on patterns as well though, because you have to be able to see the patterns through which you can re-use the code in your toolbox.
We could list rules and principles all day...the important thing to realise is that a good software developer needs to be well rounded in terms of their knowledge. This requires more than just rules; it requires principles. (Patterns are icing on the cake).
|
|
|
|
|
|
|
Last Updated 14 Jun 2004 |
Advertise |
Privacy |
Terms of Use |
Copyright ©
CodeProject, 1999-2010
