Keeping It Simple

Category: programming

  • How do the Proxy, Decorator, Adaptor, and Bridge Patterns differ?

    A user recently asked:

    I was looking at the Proxy Pattern, and to me it seems an awful lot like the Decorator, Adaptor, and Bridge Patterns. Am I misunderstanding something? What’s the difference? Why would I use the proxy pattern veses the others? How have you used them in the past in real world projects?

    Proxy, Decorator, Adapter, and Bridge are all variations on “wrapping” a class. But their uses are different.

    • Proxy could be used when you want to lazy-instantiate an object, or hide the fact that you’re calling a remote service, or control access to the object.
    • Decorator is also called “Smart Proxy.” This is used when you want to add functionality to an object, but not by extending that object’s type. This allows you to do so at runtime.
    • Adapter is used when you have an abstract interface, and you want to map that interface to another object which has similar functional role, but a different interface.
    • Bridge is very similar to Adapter, but we call it Bridge when you define both the abstract interface and the underlying implementation. I.e. you’re not adapting to some legacy or third-party code, you’re the designer of all the code but you need to be able to swap out different implementations.

    I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Good Answer” badge. This was my answer to “How do the Proxy, Decorator, Adaptor, and Bridge Patterns differ?“

  • Splitting a String in Perl

    A user recently asked:

    How do I take a string in Perl and split it up into an array with entries two characters long each?

    Ultimately I want to turn something like this

    F53CBBA476

    into and array containing

    F5 3C BB A4 76

    This was my answer:

    @array = ( $string =~ m/../g );

    The pattern-matching operator behaves in a special way in a list context in Perl. It processes the operation iteratively, matching the pattern against the remainder of the text after the previous match. Then the list is formed from all the text that matched during each application of the pattern-matching.

    I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Good Answer” badge. This was my answer to “How can I split a string into chunks of two characters each in Perl?“

  • Why Should You Use an ORM?

    A user recently asked for good arguments in favor of using Object/Relational Mapping technology:

    If you were to motivate [sic] the “pro’s” of why you would use an ORM to management/client, what would the reasons be?

    Try and keep one reason per answer so that we can see what gets voted up as the best reasons.

    I offered four answers. The first three got the most votes, but my last answer got little interest.

    1. Speeding development. For example, eliminating repetitive code like mapping query result fields to object members and vice-versa.
    2. Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don’t have to.
    3. Supporting OO encapsulation of business rules in your data access layer. You can write (and debug) business rules in your application language of preference, instead of clunky trigger and stored procedure languages.
    4. Generating boilerplate code for basic CRUD operations (Create, Read, Update, Delete). Some ORM frameworks can inspect database metadata directly, read metadata mapping files, or use declarative class properties.

    There are lots of other reasons for and against using ORM frameworks. Generally, I’m not a fan of ORM’s, because their benefits don’t seem to make up for their complexity and tendency to perform slowly. Their chief value is in reducing the time taken in repetitive development tasks.

    Hibernate, for example, is about 800,000 lines of code (Java and XML), but it’s complex enough that I doubt it’s easier to learn or to use than SQL. Besides, there seem to be fundamental tasks, such as a simple JOIN that are impossible to do through the entity interface. Please correct me if I’m wrong, but I’ve been searching tutorials and examples and I haven’t found a way to fetch a joined result set from two entities, without writing a custom query in HQL (Hibernate’s abstract version of SQL).

    I was also led to a blog by Glenn Block, titled “Ten advantages of an ORM (Object Relational Mapper).” I disagree with Block on several points. He cites some traits of ORMs as advantages where I see them as defects. He also cites features that are not specific to ORMs; they could be achieved with any type of data access library.

    update: Upon request, here are some specific comments on Glenn Block’s list of advantages of an ORM:

    1. Facilitates implementing the Domain Model pattern

    Not necessarily. I can design Domain Model classes containing plain SQL as easily as I can design classes that operate on the database via an ORM layer. Keep in mind that ActiveRecord is not a Domain Model.

    2. Huge reduction in code.

    Depends. When executing simple CRUD operations against a single table, yes. When executing complex queries, most ORM implementations fail spectacularly compared to the simplicity of using SQL queries.

    3. Changes to the object model are made in one place.

    This is not a benefit of an ORM. Many people use ORM interfaces inexpertly, so when the database structure changes, they still have to update many places in their application to reflect the change. But instead of redesigning SQL queries, they have to redesign usage of the ORM. There is no net win. They could structure their application using plain SQL queries and still be as likely to achieve the benefit of DRY.

    4. Rich query capability.

    Absolutely wrong.

    5. You can navigate object relationships transparently.

    This is definitely a negative rather than a positive. When you want a result set to include rows from dependent tables, do a JOIN. Doing the “lazy-load” approach, executing additional SQL queries internally when you reference columns of related tables, is usually less efficient. Leaving it up to the ORM internals deprives you of the opportunity to decide which solution is better.

    6. Data loads are completely configurable …

    This is not a benefit of an ORM. It is actually easier to achieve this using plain SQL.

    7. Concurrency support.

    Again, not a benefit of an ORM.

    8. Cache managment.

    This has nothing to do with using an ORM. I can cache data using SQL.

    9. Transaction management and Isolation.

    Also has nothing to do with using an ORM versus a more direct DAL.

    10. Key Management.

    Ditto.

    I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Nice Answer” or “Good Answer” badges. This was my answer to “Why Should You Use An ORM?“

  • Learn to Program in 21 Days

    A user recently asked:

    Has anyone “learned how to program in 21 days?”

    I’m not a fan of these learn how to program in X amount of days books. Some even boast, learn how to program in 24 hours. This is a joke and an insult to me as a software engineer who went through a rigorous discipline in computer science and mathematics.

    So a question to the community, have you benefited from these become a programmer quick books?

    No, it’s impossible to learn how to program in 24 hours or 21 days.

    See “Teach Yourself Programming in Ten Years,” an article by Peter Norvig (Director of Research at Google, Inc.).

    If you already have good fundamental skills at programming, and you just need a tutorial-style book to guide you through learning a new API, then these kinds of books may be helpful.

    Even then, the level of expertise will be shallow. It will take many months (at least) to become really proficient. But the quick-introduction books are useful to give you a taste of the range of functionality in a language or API.

    I’m posting to my blog the questions I’ve answered on StackOverflow, which earned the “Good Answer” badge. This was my answer to “Has anyone ‘learned how to program in 21 days?’“