| C++ MFC ATL WTL Win32 COM ActiveX Samples Tutorials Source Code Controls |
This section explains paradigms, buzz words, and "things" of modern
programming, how I see them, in 100 words or less.
It started with some discussions on codeproject,
a Gang of Many agreed that the important message of "things" we learned the hard
way is hidden behind lots of fuzz and shelves full of books shouting "buy me!".
I hope it grows.
Splitting huge projects into little actors, that interact with their surroundings
(other actors, or "the world") in a well defined way.
This is suposedly easier to understand naturally.
OOP has three paradigms: Encapsulation: you know what an object does - not how;
Inheritance: a specialist can do everything a trainee can - maybe different; and
polymorphism: a trainee can always be replaced by a specialist without you knowing or
caring.
The idea that you can plug "standard actors" together was hyped in the beginnings of OOP, but now only makes people on parties giggle and change the topic.
Proven solutions to common problems.
Instead of code examples, you use analogies: An Observer watches changes of an
object, and tells those who are interested in it. This is better than the object itself
telling everybody.
Good: It can help you pick a solid design. Bad: The
discussions are usually much up-in-a-cloud, that, once you understand a pattern from
reading it's description, it's obvious.
Patterns help reusing designs (but not necessarily code).
Does the new code pass the old tests?
Regression tests can be automated - just write a routine that does them for you.
This tends to find only a few (say 20%) of the finally known bugs, yet designing
the automated tests forces you to make a plan how to exercise the entire module
systematically - and in the end, the bugs not found is what counts.
You have a mess of code you need to fix bugs in, and add features, and you would like to "throw it away and rewrite from scratch". NO! Rather, refactor: do only small changes that either
Important: never mix these three, and make sure everything works well after each step.
The "Should I refactor or rewrite" decision is not easy, but rewrites always
take longer than you expect, with inferior results, and give you a hard time.
A group of development methods all trying to break the sluggishness of the "design everything, then implement everything, then test everything" approach that was promoted together with OOP, although they are separable. Extreme Programming is the one that gets all the "press" on the internet. Requirements change, and AP can incorporate what "classic" design did not dare to name.
A set of rules that enforce knowledge sharing in your team ("move people around", "programming in pairs"), rigorous automated tests (write unit test routines before the actual code), and short deveopment cycles (frequent check-ins, frequent releases, customer always available). To cope with ever-changing requirements, "refactor mercilessly" - i.e. spend time on improving the existing code.
bitbucket: Framed Index | non-framed Index (ugly)