This Blog


Favorite Posts


January 2011 - Posts

  • DevExpress Newsletter 41: Message from the CTO

    This time around I’m continuing my discussion of the SOLID principles with O.

    The O in SOLID - The Open-Closed Principle

    Let's continue our discussion of the SOLID principles. Today we'll look at the O in SOLID: the Open-Closed Principle.

    First proposed by Bertrand Meyer in 1988, this goes like this: Software entities (such as classes and functions) should be open for extension but closed for modification.

    Seems a weird way of saying it, but in essence this is saying that any class (or whatever) you write should be written in such a way that it can be used as is, be extended if need be, but never needs to be modified. In other words, use the class in any way you need but modifying its behavior comes by adding new code, never by modifying or deleting the old.

    How on earth do we do this? The answer is through abstractions. Back to my example binary tree painting code I'm using to discuss these principles. If you remember from last time, I split the tree painting code into code that navigated the tree and code that painted the nodes and edges.

    There is still a problem though: if my tree navigation code holds a reference to the node painting code, I'm no further forward than I had been. I can still only draw trees as I did before. What if I had another graphics library? What if I had another surface (paper? bitmap?) that I wanted to draw on?

    Unfortunately, as I wrote it, I'd have no option but to rewrite large chunks of my node painting code in order to support such scenarios.

    What should I have done in the first place? Abstracted out the graphics context so that it covers things like create the context, draw a line from A to B, draw a filled circle at X, and so on. Once I have that -- for example as an interface if I were using C# -- then I can write a concrete class that fulfills the interface and pass that in to my tree painting code. If I need to draw on paper, I again just write a class that implements the interface and away I go. No need to change the tree painting code at all: just abstract out the main features of the painting code and supply the instance of a concrete class at run-time.

    Abstractions are good. Referencing concrete classes is bad.

    You can watch the video here.

    Simple enough: write your classes in such a way that others can use them as is and don’t have to crack open the source code. Kind of puts the kibosh on the whole sealed keyword in C# if you ask me. Another way of looking at this is that it indicates using composition in your class/object model.

    For Uncle Bob’s chapter on the Open-Closed Principle, click here for the PDF.

    (Here are the links to the other principles: S O L I D.)

  • Ask DevExpress webinar: Meet the VCL Team

    Just a quick note to let everyone know that 2 weeks today, on Thursday 27 January, at 10:00am Pacific Time, I will be hosting a webinar with our VCL team. Register here.

    Come join us and meet the team, ask about our VCL products, our news and roadmap for 2011, and what we think of the possibility of 64-bit Delphi. It’ll be a blast. See you then!

  • Using Communicator 2011 on a MacBook Pro to connect to Microsoft Lync 2010

    If this saves someone some time, it’ll all be to the good; you wouldn’t believe how much time I wasted this morning on getting it to work. Unless you fall into the small section of the population who fit under that SEO-friendly title I wouldn’t bother continuing to read.

    Screen shot 2011-01-12 at 7.45.13We at DevExpress are trying to find a better way to communicate. With staff all over the world, sometimes it’s hard to keep in touch. Over the past couple of weeks or so, we’ve been evaluating Microsoft Lync 2010 (previously known as Office Communications Server or some such). It’s all fine and good if you have Windows PCs across the company, but we have — shock, horror — a few Macs. Including this 13” MacBook Pro I now use for my day-to-day work.

    I haven’t abandoned Windows completely of course: I still need a way to use Visual Studio for a start, and Windows Live Writer is still the best way to publish blog posts. So I have a virtual machine set up and use VMWare Fusion to serve it up. Last week while I was in the offices in Glendale we set up the Lync Communicator program in my VM and very nice it was too. Unfortunately, I don’t as a matter of course start up the VM in the morning and have it running constantly. Indeed the opposite is usually the norm: I only start the VM when I need to use those couple of apps I only have in their Windows versions. So, all in all, a bit of a waste.

    This weekend I did a bit of research to see what I could do. It turns out that most of the Google hits out there were for previous versions of Microsoft Messenger for the Mac whereas I use Office 2011. It seems with the new version of Office for the Mac, Microsoft made Messenger “personal” and restricted it to only work with Windows Live. No Lync support. Well, fooey to that.

    They did, however, create a “business” version that does work with Lync and called it Microsoft Communicator for Mac 2011 (it’s currently at version 13.1.0). So, I just install that and everything will be groovy, right? Short answer: no. Long answer: <gales of hysterical laughter>.

    Here’s how to do it.

    1. Download Microsoft Communicator for the Mac 2011. I got mine from my MSDN subscription. I don’t think it’s available as a public download. I also don’t know if it’s part of the Microsoft Lync Server download (I’ve not been involved in the setting up of the Lync server).

    2. It’s an iso file, so just mount it and install it in the usual way on your Mac. When it asks you for your login details, ignore it and cancel out.

    3. Now the fun step. It seems you have to install a certificate as a root certificate on the Mac in order for Communicator to work securely (briefly: the TLS connection needs an X509 certificate to authenticate the server). Azret gave me the URI on our NAS for ours, so I just double-clicked it from within Finder. A Keychain Access dialog came up asking me if I trusted the certificate. I clicked “Always Trust”, and... nothing happened. The certificate wasn’t added. If I tried to login with Communicator (you need your email address, user id, and password), I got this:

    Screen shot 2011-01-12 at 7.01.47

    Obviously that’s not the way to do it, so I did more searching.

    3 bis. This is where it gets squirrely. A lot of the advice out there is for the earlier Leopard version of Mac OS X or is for earlier versions of Messenger for the Mac and talks about having to add the X509Anchors keychain to the list in the Keychain Access utility (although it’s there by default in Leopard) and then adding your company server certificate to that. Sometimes, this advice forgets to add the word “Leopard” making it seem as if it’s valid for all versions of OS X. Since the keychain by default is restricted to writing, you have to issue chmod commands and such to open it up for modification. (See here for an example of such advice, although it does talk about SnowLeopard. Here’s a TechNet article that also sent me down another rabbit hole.)

    The answer for SnowLeopard is actually very simple: open Keychain Access (it’s in /Applications/Utilities, although I tend to just use Spotlight to find apps); drag the root certificate to the login keychain; on the dialog that comes up click Always Trust.

    4. Start up Communicator for the Mac, type in your email address, user id, and password (I also click the remember password checkbox) and click Sign In. Communicator starts up.

    5. (This one’s a bummer.) It seems that Communicator for the Mac does not use Growl for alerts but instead uses its own system. Yah. Boo. Sucks.

    Screen shot 2011-01-12 at 7.26.18

    As you can see, I set the dock icon bounce to Continuously (the default is Once Only). That way, if I miss someone pinging me immediately, at least I have a better chance of seeing it fairly quickly. I prefer Adium’s bounce once every 5 seconds option though.

    Anyway: if you use a Mac and have to connect to your company’s Lync Server for inter-office communications, I hope this post helps.

  • Supported IDEs for our VCL products going forward

    After getting lots of excellent feedback on my post about the roadmap for our VCL products (thanks to everyone who responded!) and having had some discussion internally, we’ve extended the list of IDEs that we will be supporting in the future for our VCL subscriptions.

    Flex Array on Production Line 2photo © 2008 milolovitch69 | more info (via: Wylio)As I stated before, we have to do this in order to be more efficient in our releases and to maximize our ability to provide new functionality in those releases. Supporting the current list of 14 IDEs and compilers (well, I think it’s 14: Delphi 6, 7, 2005, 2006, 2007, 2009, 2010, XE; C++Builder 6, 2006, 2007, 2009, 2010, XE — yep, 14) means that a great deal of time and resources are spent in testing and supporting our products for these compilers and the 8 versions of the VCL that they require (well, I think it’s 8, etc). We’re also cognizant of the fact that it’s very likely that Embarcadero will be releasing another new version of RAD Studio this year and that this release may even have 64-bit support. At that point, the amount of effort needed for supporting and testing our controls will be quite alarming: 18 compilers. That’s 10 different versions of the VCL, to put it another way. Frankly, our VCL team would rather be writing new functionality to make our subscriptions even more valuable.

    Since many people, rightly or wrongly, didn’t view RAD Studio XE as a worthy upgrade from the 2010 release, we’ve added back Delphi and C++Builder 2010 into the mix. The list of supported IDEs and compilers will be 7:

    • Delphi 7 (just because it’s still very popular — come on, people, upgrade already)
    • Delphi & C++Builder 2007 (the last ANSI string version)
    • Delphi & C++Builder 2010 (the current popular version for Unicode support)
    • Delphi & C++Builder XE (just because it’s the latest version)

    (And the relevant RAD Studio versions as well, of course.) Let’s call these the primary compilers, and the others not mentioned the secondary compilers.

    Now, what does this exactly mean? Firstly it means that the primary compilers are the only ones we shall officially support. If you find an issue using a secondary compiler then our first step will be to see if it’s reproducible with the “nearest” primary one (actually we’ll probably test either side). Secondly it means that, although secondary compilers are no longer supported, it’s unlikely we shall be removing any $IFDEFs that cover them, at least not immediately. It’s likely therefore that the products will continue to work with the secondary compilers at least for a while, but it’s not guaranteed. Indeed, it’s more than likely that the code will start to “decay” for those compilers: some things will continue to work and others will break as we add new features and fix other bugs.

    As I said before, we have to simplify our mix for our VCL products. This means subscriptions, no individual products, and a reduction in the number of environments we have to support. Once this is fully in place, we can move on to provide even more great functionality and features for VCL.

  • DevExpress Newsletter 40: Message from the CTO

    I’m in the DevExpress offices in Glendale this week, and it’s back to the videos again since I can just walk into our studio and be recorded. To celebrate I thought I’d go over the SOLID object-oriented design/programming principles over this and the next four newsletters; principles first set out in their current form by Robert Martin.

    The S in SOLID - Single Responsibility Principle

    It seems amazing to me that I've been developing with object-oriented design and programming for some twenty-odd years. I well remember when I started doing so and the only worries I seemed to have were in getting the syntax right and wondering whether a method had to be virtual or not.

    Over the two decades since then we've all become rather better at writing object-oriented code, not just me. I thought I'd discuss a well-recognized set of principles that have helped many people become better object-oriented programmers: the SOLID principles, where SOLID is an acronym with each of the five letters denoting a separate principle. These principles were first described in their current form by Robert Martin, also known as Uncle Bob.

    Today we'll look at the S in SOLID: the Single Responsibility Principle.

    This perhaps is the most difficult principle in the SOLID collection to grasp. Here's how Uncle Bob puts it: There should never be more than one reason for a class to change.

    Let's take a look at an example from my own code.

      class TreePainter {
          void DrawRoot(...);
          void DrawChildren(...);
          void DrawRightSubTree(...);
          void DrawLeftSubTree(...);
          void PaintNode(...);
          void PaintEdge(...);
          void PaintData(...);

    A while back I was investigating red-black trees and I wrote a tree painter class to render a simple binary tree to the screen. It had methods that recursively navigated the tree being drawn (these are called Draw such-and-such) and it had methods that drew the edges and the nodes themselves (these are called Paint such-and-such). In my original code these were all named Draw such-and-such, just to make the distinction even harder to spot.

    Very nice it was too, until the day when I wanted to use the same code for drawing a tree using a different graphics library. Suddenly the mix of tree navigation and node/edge drawing became a liability: the tree navigation code didn't need to change but the drawing code did.

    In essence, my tree painter class did not conform the the Single Responsibility Principle. It did two entirely separate things: navigation and painting. When the latter area of responsibility changed, the whole class was compromised, despite the fact the navigation was the same.

    The solution was to break out the node/edge painting from the tree navigation and make them separate classes. In fact, this separation of responsibilities made it easier when I modified the node painting logic to work with red-black tree nodes, which was yet another vector of change.

    All is not a bed of roses though. The problem with the Single Responsibility Principle is that you may make your code more complex and decomposed than you ordinarily would, all for some future eventuality that may never come. If, for example, I'd never needed to use some other graphics context or needed to render red-black trees, my original code would still be working just fine today.

    You can watch the video here.

    With all this principle (and the next four to be published in subsequent newsletters) I’ve found it pretty hard to find examples in my own code to illustrate the “before” picture. I think that, once you get used to the SOLID principles, you automatically (unconsciously?) switch into using them all the time and so your own code will be better designed and decoupled. This example I showed here was essentially an early cut at the code: I decoupled it fairly early on as you’ll see if you read the articles I wrote.

    If you want to read the series of articles I wrote on red-black trees, start here.

    For Uncle Bob’s chapter on the Single Responsibility Principle, click here for the PDF.


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners