Blaine Buxton: Positronic Vibrations From Alto Dorado

Alright, I spent the weekend playing around with Squeak and came up with the following snippet:

| allProjects  doBlock |
allProjects := ((Project allProjectsOrdered copyWithout: Project current) 
   addLast: Project current; yourself) 
    readStream.
doBlock := 
 [:project | | enterBlock exitBlock |
 enterBlock := [(Delay forMilliseconds: 1000) wait. allProjects next ifNotNilDo: [:next | doBlock copy value: next]].
 exitBlock := [World removeActionsWithReceiver: enterBlock].
  project world
  when: #aboutToEnterWorld send: #value to: enterBlock;
   when: #aboutToLeaveWorld send: #value to: exitBlock.
  project enter].
doBlock copy value: allProjects next.

It basically makes a slideshow of your projects and shows them one second apart. The obvious solution didn't work:

((Project allProjectsOrdered copyWithout: Project current) 
  addLast: Project current; yourself) do: [:each | 
   (Delay forMilliseconds: 1000) wait. 
   each enter]

The reason is that when a project is switched, all of its threads are terminated on exit. This makes sense if you think of each project as it's own "world". So, I quickly whipped out the code in the first snippet. It was basically an understanding for me to try out different things. There's so much to explore and learn.

I want to give my presentation in Squeak and show off our great environment. I'm having fun playing around. It's funny, I've been a Squeak developer for at least a few years now and still haven't fully explored Morphic. Mainly, I've worked on backend frameworks or Seaside. But, I dabble every year for a small amount of time. The presentation will give me a reason to more fully explore the untapped potential.

posted by Blaine at 10:40 PM |  1 comments |  Post a Comment

Needle (the next version of HttpUnitTest) has been in research mode for quite some time now. I've been mainly trying different paths and see how they feel. One thing that I thought would be great would be able to test javascript as well as HTML. Right now, HttpUnitTest is 100% Smalltalk, but I thought it would be better to able to express tests in Javascript and run the tests in the browser. This is similiar to the approach of Selenium, but I wanted to do it like we did on HttpUnitTest. I love the API of HttpUnitTest. It's simple and allows for more flexible checks. It's also more object-oriented in that I'm not checking text, I'm looking at tagged values.

Here's an example from the HttpUnitTests:

 | browser |
 browser := self browserClass on: 'http://localhost:8008/seaside/go/counter'.
 self assert: (browser h1 allSatisfy: [:each | each text = '0']).
 self assert: (browser a text includesAllOf: #('++' '--')).

 browser click: [:a | a text = '++'].
 self assert: (browser h1 text includesExactly: #('1')).

 browser click: '++'.
 self assert: (browser h1 text includesExactly: #('2')).

 browser click: '--'.
 self assert: (browser h1 text includesExactly: #('1')).

This is a test for the counter example in Seaside. Basically, you create a browser object and point it to an initial url. From there, you navigate by finding a hrefs and form submits. To verify, you simply nagivate the current page in the browser. You do this by simply sending the html element name to each level you want to look at.

For example, when you send the #h1 to the browser object, it returns all h1 elements it finds in a collection. You then, further constrain what comes back by sending the message #text which actually returns a collection of all the contents of the h1 tags. It works exactly like XQuery. But, we're doing it with messages. Pretty cool, huh?

HttpUnitTest makes extensive use of doesNotUnderstand: and generating code on the fly for its simple API. It's a trick that allows us to be more succint and still have all the power of Smalltalk. But, we don't have doesNotUnderstand: in Javascript. What are we to do? I played with several approaches and finally decided, "What if I took a functional approach?" What if I return a function instead of a collection? So, the above example would look like:

find(document, 'h1').includesExactly(['1'])

The initial find function simply is the seed and return functions that we then send in element names. The cool thing is that functions are first class objects in Javascript so they can have other functions and data hanging off of them as well. I was shocked when I first implemented this to only check for element names (other bells and whistles forthcoming) was very short. Here's the code:

    function forEach(array, func) {
        for (var i=0; i < array.length; i++)
            func(array[i])
    }
    
    function findChildrenFromElement(anElement, name) {
        var upper=name.toUpperCase()
        var left=[anElement]
        var result=[]
        while (left.length > 0) {
            var next=left.shift()
            if (next.nodeName == upper) {
                result.push(next)
            } else {
                forEach(next.childNodes, function(each) {
                    left.push(each)
                })
            }
        }
        return result
    }
    function findChildrenFromArray(anArray, name) {
        var result=[]
        forEach(anArray, function(each) {
            var subResult=findChildrenFromElement(each, name)
            forEach(subResult, function(eachResult) {
                result.push(eachResult)
            })
        })
        return result
    }

    function findAll(anArray, aString) {
        var innerResults=findChildrenFromArray(anArray, aString)
        var result=function(newSearch) {
            return findAll(innerResults, newSearch)
        }
        result.contents=innerResults
        return result
    }
    
    function find(anElement, aString) {
        return findAll([anElement], aString)
    }

The seed function find really is simply a call to findAll which is a recursive call to itself, that returns a function calling itself on the next call and the results are stored in an instance variable of the function called contents. The hard worker is findChildrenFromArray. He searches the DOM model for matches of the element name and returns the top results (it stops searching when it finds a match). The rest are support functions.

To expand on this further, the only thing that needs to change is the element name check to make it more general since we're going want to find elements based on attribute values and inner text matches. And wouldn't it be nice to use regular expressions as well (like find me all tags that match h[1-6]). The only thing that would need to change is to send a dicriminator function to findChildrenFromElement instead of the name and use it to check for a match.

I was shocked how little code this was and I have not lost any of the expresssibility of the Smalltalk version. The extra parenthesises are a drag, but it's a small price to pay to test not only your html, but also your javascript. The next research item was to integrate with JSUnit. So, I could use the same framework for testing my web pages. I could test my javascript and html together. I'll keep you posted.

Oh you might be wandering, where is Smalltalk going to be in Needle? Well, right now, my thoughts are it will be driver and it will generate the Javascript needed to test. My thought right now is that I don't want to leave my Seaside environment, but still test everything. I want the feel of HttpUnitTest, but the piece of mind knowing I'm testing not only my html and navigation, but my Javascript as well. I also want Needle in more environments as well. I'm thinking it would be nice to have a version for Java and Ruby. We'll see.

posted by Blaine at 11:29 AM |  2 comments |  Post a Comment

I realized that I have yet to blog about my presentation at Smalltalk Solutions! For those interested, I will be giving my talk on April 26, 2006 @ 1:00-1:50pm. I hope to see a lot of people there. This is my first conference talk and I'm so excited. I'm nervous. It's an honour to share the stage with such great thinkers. I can't wait! Anyway, here's the details from my proposal:

Typically, unit testing ensures that individual pieces of an application work as expected. However, in practice this can easilylead to a state in which we settle to have just a minimum level of confidence in our code, like some sort of silly mistake insurance. But, what if we looked at testing as a means to prevent and eliminate pain, to actually increase the amount of confidence we have in our work by pointing at places where the cost of change needs to be reduced?

Smalltalk has a highly reflective and lively environment that can be used to augment traditional unit testing. It allows us to do things that are only dreamed about in other environments. We can easily question and interrogate code or any aspect of the system. It is not hard to implement tests to ensure code correctness, enforce metrics, and scrutinize resource allocations.

This power can be used to prevent pain by working inside the unit test framework. For example, you can have a metric test which, upon reaching some threshold value, presents a failure with the top offenders. Moreover, you can even check that resources are cleaned up properly between each test, and fail if proper procedure is not performed. You can even verify that private messages are not sent outside the class and that deprecated methods are no longer used.

You can be creative and take the stance of using tests to stop and minimize the cost of change. There is a large variety of characteristics that can be tested, from run-time correctness to code quality. This presentation will give real world concrete examples in Smalltalk.

posted by Blaine at 5:10 PM |  0 comments |  Post a Comment

Before Christmas, Brian Foote made a blog entry about "The Least Understood Thing in Computing". His answer was simply "reflection". Sadly, I think he is overtly optimistic. I agree that an understanding of "reflection" is badly needed. Reflection is what makes frameworks like Hibernate and Spring possible. But, I still think they could go farther.

But, I would have answered: "encapsulation". Designs with properly encapsulated objects and layers make for great architectures. But, I've seen far too much code that exposes various aspects of the internals of the layers unneedlessly. Designs that are comprised of merely data structures and processors are complex and hard to maintain. The benefits of Good OO Design are well known and they are several good teachers. But, I keep running into procedural poo that refuses to encapsulate the internal workings of itself. Now, before anyone gets uppity, I know you can do great design in procesdural langauges as well. Information hiding works there too via modules.

I read Parnas's "Some Software Engineering Principles" article in which he talks about how easy it was for programmers to dissect programs into flows, but it was difficult to break them into modules (or objects). One of our greatest tools to aid in fighting complexity and increasing understandability is "encapsulation". Look any complex system and it will be comprised of several easy to understand sub-pieces that work well together as one cohesive. The human body is an excellent example of this. We are comprised of different systems that are comprised of even smaller systems. Nature is recursive with a keen eye for hiding information at each layer.

I think everyone in computer prgoramming knows that encapsulation is a good thing, but it's hard to achieve and is it really understood? I see designs that expose their internals all the time. It's something that is preached, but practiced in pockets. Accidental architectures arise from information exposure. Knowing what to expose and what to hide takes thought and planning in design. It just doesn't happen.

This post might seem pessimestic, but it's really a rally cry for doing better. Software projects succeed and fail for various reasons. But, I think a mixture of good technical leadership, shared vision, and good design is at the core of every success. The heart of good design is encapsulation and failure rates of 60% plus tell us we can do better. Let's start with good designs. The Pragmatic Programmers has several articles on good design and you could even pick up "Software Fundamentals" by David Parnas.

posted by Blaine at 2:19 PM |  0 comments |  Post a Comment

I finally got around to using Dolphin 6 this weekend. I upgraded my projects in no time. I had a few problems but, they were because I called private methods without realizing it (the gods of encapsulation spoke and smited me). Truth be told, my tests found all of the problems except one. Nice.

Enough about my projects, "How is it?" you ask! Let me tell you it is a gorgeous front-end. The text editor also jumps up at you. The auto-completion is extremely accurate and helpful. I never thought I could be more productive in Smalltalk, but the guys at Object-Arts have proven me wrong. The second thing that you notice is the graphical layout tool. It is improved greatly! It now gives you examples to look at and it's simply easier to work with. I love it! You'd think they would stop there, right? Nope, they also added version control (which I was using in Dolphin 5) which works a lot like Envy.

But, wait there's more! Not only do you get all of those things, you also get this thing called "Idea Space". Basically, it's like a tabbed web browser (ala FireFox and Opera) for coding. It took a little while to get used to, but the boys used to programming in Eclipse are going to love it!

All in all, Dolphin 6 is even more fun to program than Dolphin 5. Other Smalltalk vendors should take note. The UI is awesome with lots of bells and whistles that aid you in producing and examining code. I did find some bugs, but apparently they've already been fixed. Overall, a solid product that was worth the wait. I can't wait to explore the changes in the object libraries. Treasure awaits!

posted by Blaine at 9:17 PM |  2 comments |  Post a Comment

A lightweight stick that is used to beat down arguments in XP projects. I came to XP thinking that the above mantra was the greatest thing since sliced bread. I still think it's a great mantra, but it needs to be taken with a grain of salt. Why? You might ask. I have seen it used too many times to disregard a potentially good idea simply because someone didn't want to think. To me, agile is about being pragmatic and delivering business value without unneeded overhead. This takes care, patience, and most importantly thought.. I get frustrated with XP because of the dogmatic mantras that developers sling around to avoid pondering alternative solutions.

I believe you should at least reason about your problem a little bit before coding. Just don't jump right in and start coding away like a mad man. I'm not talking about documenting detailed UML models with long descriptions before coding either. A simple whiteboard session to get the bird's eye view. I've found an hour or less is perfect. I find that flushing out ideas in front of a whiteboard before coding gives everyone the vision to implement the code correctly. Vision is an important aspect of team software. It gives everyone the high level perspective to know how their piece will fit in. It also gives everyone ample opportunity to speak their ideas. But, I have found in XP that coding is the king and that vision is never matured and every pair implements their piece. Guess what? The pieces don't always fit. So, we have to refactor mercilessly where a simple whiteboard session could have saved hours (and in some cases days). A stitch in time saves nine. How true.

The fact that some developers use the mantras, "Do The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need", to shoot down ideas and be the devil's advocate is annoying. It's used when an idea is not understood by certain members of the team (which is not a good thing, but discussion helps understanding). I've seen this phenomenon too many times to count. Being agile doesn't mean throwing your brain out of the door. The confusion arises in the fuzzy nature of these sayings. From who's perspective are we talking? Simplest for the developers? The users? The managers? Who? I generally take it to mean "The Users". But, most developers take it to mean simplest for them. And then, there's what people's definition of simplest is. Some think simplest means easiest and others think it means most convenient. Ironically, I take the simplest possible thing for the user and using the simplest (not the easiest, but the one with least moving parts) design. Sometimes, I think I stand alone on this. But, I know other developers take the same definition.

For example,what is simplest XML files or relational databases for object storage? Now, before I even get started it is true that you can hide the storage mechanism behind objects and plug-n-play the solution. But, is it really that simple? While, yes, in theory, I should be able to unplug one solution and plug in the other using the strategy pattern. It assumes developers will never break encapsulation (aka "Look at that private method, change it to public! We need to use it!) and the discipline is in place to make sure the interface is strictly enforced (aka "Look this interface is too coarse grained...let's add a bunch of small grained methods...this ain't no sippin' broker!"). In practice, you will have developers of varying expertise and once encapsulation is broken, you can no longer plug-and-play your solution without major refactoring. Also, little assumptions are made along the way that can degrade the quality of the interface (aka "Man, this file broker performs awful! I know, let's create a summary object and store it as well!"). Again, I get back to developers need to have discipline and vision so that the design allows the strategy pattern in our storage brokers to remain in tact. Otherwise, our interface is compromised and our membrane of encapsulation collapses into endless refactoring.

OK, I got off the discussion of XML files versus relational database storage. Which is simplest? You could argue that file storage is the simplest from the point of view of just storing objects. Right? If you are at the point of deciding storage, you are in the infant stage of your new product. Files will be nice to get the objects right before dealing with the headache of OO to relational mapping. So far so good. We are being pragmatic right? But, what about the view point of concurrency? ACID transactions? searching? Are files still the simplest possible thing? I don't think so and here's why: relational databases have been tuned by experts, people who make a living thinking about transactions, concurrency, security, and searching. All of which are not trivial topics. Now, my purpose in my job is to deliver value to my customers. How is making a file system searchable, concurrent, and acid delivering business value? It's not. So, I pay a small penance to the complexity gods to enjoy the fruits from the blood of the experts. You have to look at the bigger picture. Delivering a production enterprise system using a file system is bordering on gross negligence. I know it has been successful for certain startups (Paul Graham comes to mind, but he had the "best of the best" working for him, I'm talking general enterprise development in corporations). Of course, an even easier solution would be to use an object database, but I realize it might not be an option for everyone.

You might be thinking that I am against "Doing The Simplest Possible Thing", but I am not. I think it should not be a gauntlet that is thrown to stop arguments. I don't think it should end discussions. In fact, I think it's a value that doesn't need to be brought up in discussions. It's something to internalize and not used to make your easy solution win. You live and breathe it. You show others through example. I consider myself to be agile and not XP. I'm deeply pragmatic and think about my solutions. Dogmatic mantras are tools to not use your grey matter. Simple solutions do not just pop out of thin air. The simplest thing takes thought and understanding of the problem from all angles. It also takes practice and knowledge. The worst idea is to only have one. Experts make the simple look easy. How many people read the GoF patterns book the first time and said to themselves, "Wow, why didn't I think of that?"

posted by Blaine at 10:28 PM |  4 comments |  Post a Comment

When I'm having a bad day at work, I put on "The Sound Of Perseverance" and it picks me up. It's one of the few albums that speaks and touches me deeply. I wish Chuck could have stayed. These are the lyrics that gave me strength today:

What pain will it take
to satisfy your sick appetite
go in for the kill
always in sight-prey
the time always right-feast
feed on the pain-taste
sorrow made flesh-sweet
live how you want
just don't feed on me
if you doubt what i say
i will make you believe
shallow are words from those who starve
for a dream not their own to slash and scar

I miss you, bro!

posted by Blaine at 9:28 PM |  0 comments |  Post a Comment

I thought it would be fun to share my favorite albums of 2006 with thoughts.

1. Coheed And Cambria-Good Apollo, I'm Burning Star IV
   By far my favorite album this year! I had gotten their previous album 2 months before the release of this mammoth. I quickly fell in love and bought their first disc as well. I love this band so much. Their music is just simply incredible. I love the fact that they can make a 9 minute song sound like 3. I totally lose myself in this album. The bass player is simply phenomenal! A great mix of rock, metal, prog, and pop. The music is diverse yet it all fits into a cohesive whole. The live show was incredible too!


2. Arsis-Diamond for Disease
   I swear these guys are channeling Chuck Schuldiner! I miss Chuck's music greatly and these guys deliver up a tasty mixure of extreme melodic metal zaniness. I love it. They remind me a lot of later era Death with more gusto. It's passionate and these guys are the future of death metal.


3. Clutch-Robot Hive-Exodus
   These guys groove so hard. The go-go bits are brilliant and the music simply crushes. Besides, any band that works the lines, "Rocking with Dokken" and "Tipping Cows in Fields Elysian" into their music has got my vote. Clever lyrics and great songwriting. These guys should be huge. I can't wait to see them live. It took me awhile to get into them, but this album is the one that sold me!


4. Story of the Year-In The Wake of Determination
   Anthemic pissed off music. This is basically old school thrash with a great singer. Emo my ass. This is great stuff. Who needs the next Metallica when you have this?


5. Crowbar-Lifesblood for the Downtrodden
   HEAVY. I love Crowbar. They are the kings of consistent output and never disappoint. Crushing.


6. Alice Cooper-Dirty Diamonds
   The master returns and this time it's his best in years. This albums shows all the facets of Alice in a classic rock setting. I hope Alice keeps making them like this.


7. Biomechanical-The Empires of The World
   This took a few spins for me to love it. It's technical thrash with lots of riff changes. It will make you dizzy, but once you get used to the curves in the track, this is one fun rollercoaster!


8. Vendetta Red-Sisters of the Red Death
   Surprise album for me. The subject matter will make you squirm, yet they make it sound so catchy. This one got stuck in the player and I love to sing along to it. Of course, people probably think I'm strange.


9. Pig-Pigmata
   PIG returns with his best album! Careful arrangements and clever electronics are spreadout this tour de force of what Pig does best. He gives you a good sampling of what he's up to and it makes for an interesting and never boring ride.


10. Thrice-Vheissu
    Wow. "Artist in the Ambulance" was good, but this just sets the standard to a new high. Super catchy music that stays creative without tripping over itself or being too self indulgent.


11. Candlemass-Candlemass
    Messiah returns with the might Candlemass and quite frankly Messiah can make sound great. His voice is just unmatched. Of course, the rest of Candlemass outdid themselves on this comeback disc. It's like they never left. Oh, this band throws me back to my younger years. What fun!


12. Dredg-Catch Without Arms
    Another surprise band for me. It took me a few listens to grow into this disc, but what we have is catchy atmospheric rock. I can't describe this band well, but I know I love them. Tight band live too.


13. Bloodbath-Nightmares Made Flesh
    FUN. Simply put. This is another throwback to my old years when we would sing the sickest lyrics and laugh ourselves silly. Mad fun. Great old school death metal with tongue firmly in cheek.


14. Corrosion of Conformity-In The Arms Of God
    Black Sabbath worship. Man, they have the grooves and feel of old school Sabbath without becoming a copycat. The whole southern heavy vibe is just awesome. The lyrics as usual are great. They brought back the politics and turned the volume up again! I don't care, this band always puts out something good and you never know quite what to expect. It's always a little bit different.


15. Firewind-Forged By Fire
    Anthemic power metal that's just fun. Lots of great guitar work to boot as well. It goes a little overboard and I love it for that. This again takes me back to the old days of power metal. Mad fun again!


16. System of a Down-Mezmerize/Hypnotize
    I never heard anything before this band, but I love both of these discs for their quirky nature. The goofy lyrics and never know what to expect make these a fun listen.


17. Russell Allen-Atomic Soul
    WOW! The voice of Symphony X outputs a disc that trumps his main band! He wrote all of the music and played most of the instruments. What we get is a spirited romp through rock history. Again, this is an album to put on and just crank the volume!


18. Confessor-Unraveled
    OK, I loved this band when I was younger, but I have never heard a comeback album like this. Simply put, this is their best album and it spent a lot of time in my player. Slowly played doom with a great singer and progressive flourishes. Great musicianship and songs. I can't wait for the next!


19. Chiodos-Alls Well That Ends Well
    It took me a little while to get into the singer on this album, but I'm glad I did. The music is fantastic. I love the keyboard player.


20. Avenged Sevenfold-City of Evil
    I hated the song "Bat Country" when I first heard it because the singer didn't click with me, but once I gave the song a chance, I loved it! These guys suck you in with an old school sound with a punk feel. It's got urgency and enough to hooks to sink a battleship.

Honorable Mentions:
Funker Vogt-Navigator
Between The Buried and Me-Alaska
Arch Enemy-Doomsday Machine
Nevermore-The Godless Endeavor
The Fall of Troy-Doppelganger
The Design-Into The Moat
Grand Magus-Wolf's Return
Porcupine Tree-Deadwing
Roadrunner United-The All-Star Session

posted by Blaine at 8:58 AM |  0 comments |  Post a Comment

The Smalltalk and Ruby user's groups have been combined into the new and exciting Dynamic Language User's Group. The new group will be about all dynamic langauges. So, we'll be talking about a lot of languages. The first meeting will be on February 7, 2006. Our first topic will be DynAPI which is cool Javascript open source project and presented by Brent Adkisson. Our meeting place and email list has changed too. I hope to see everyone! Sign up for the new list!

When	First Tuesday of the month, 7pm-9pm
Where	Cafe Gelato 156th & Dodge 445-4460

posted by Blaine at 10:33 PM |  0 comments |  Post a Comment

Look! I will be a speaker at Smalltalk Solutions 2006! How cool is that? The speaker list is impressive and I'm anxious to meet both Avi Bryant and Brian Foote! April can't come quick enough!

Seriously, my presentation is based on some of the stuff I've been blogging about meta-testing. I plan on doing a java version of it as well once Smalltalk Solutions is over. It will be interesting to see the different implementations.

posted by Blaine at 9:42 PM |  1 comments |  Post a Comment

It's not everyday you can read find well-written Javascript code, but I found some great examples in the DynAPI. It's a Javascript library with all kinds of goodies and it even has an editor that's all Javascript as well. Pretty cool stuff....I'm still looking through it all, but from the examples, it's plain simple!

I'm impressed!

posted by Blaine at 9:17 PM |  0 comments |  Post a Comment

From Relevance:

...2006 will show that dynamically typed languages are a fad and Java and .NET will again rule the day, and especially that 2006 will be the year that we see one spectacular failure of Ruby in the enterprise and this will be the death knell of this trend.

I don't wish failure even on my worst enemies. I can't believe somebody would blog such trite. Dynamic languages are a fad? Please. Lisp is the grand daddy of them all and what year was it conceived? Hint: It was WAY before the birth of java and .net.

Why can't we all just get along? I've been apart of successful java and smalltalk projects. Each had their own unique challenges. Developers are attracted to each because of their experience and success with their choice. Why wish failure? Are you feeling threatened? I keep hearing "the hype machine" from java folks and I just wish they would go back to 1997 and realize that they were "the hype machine" back then. Is java fad? Far from it. But, Smalltalk and the recent crop of dynamic languages are not either. The important thing is to ask, "why is there hype around THIS technology?" instead of demoaning everyone's enthusiasm for it. I find that everytime developer's get excited, I start asking that question. The discussions are always lively and I walk away with a different perspective. We should all be learning from one another instead of bitching that the newest toy is not ours.

It's a big world. There's room for all of us. I wish everyone no failures and only successess this year. No matter what your technology choice is!

posted by Blaine at 8:58 PM |  0 comments |  Post a Comment

I would love to listen to your new CD "A Beautiful Lie", but you have copy-protected it. I prefer to enjoy my music on my mp3 player because I have a plethora of choices at my fingers. But, you have prevented me from ripping my music to mp3 for my enjoyment. I only listen to music on my mp3 player and sure, I could rip it with different technology (like WMA), but why be different just for you? I have software that makes sure the volume levels between albums are consistent and I can not do that with your options. You've also made me feel like a common criminal. I never share my mp3s and buy every piece of music that I have on my player. So, I will not purchase any more of your CDs and enjoy any of your music. If I were you, Thirty Seconds To Mars, I would switch labels because I will never purchase any of your CDs while on Virgin.

posted by Blaine at 5:59 PM |  0 comments |  Post a Comment

In my previous post, I was writing about how I was using java's reflection API to make sure that my domain objects were conforming to the constraints of the Hibernate project. So, my objects could be persistable by anybody. At one point, I needed to know if a class was abstract (because then I know I culd't instantiate it) or final (because then this cuts down on the possibilities that Hibernate can do for proxies). Here's the code that I used:

    private boolean isAbstract(Class klass) {
        return (klass.getModifiers() & Modifier.ABSTRACT) > 0;
    }
    private boolean isFinal(Class klass) {
        return (klass.getModifiers() & Modifier.FINAL) > 0;
    }

What does this have to do with encapsulaton and minimal interfaces? In the code, they are odds with one another. The minimal interface is to simply have the getModifiers() method, but I believe this breaks encapsulation. I'm basically being exposed to how modifiers are implemented in the object, Class. Should I care that modifiers are really integers? If I got rid of the getModifiers() method and replaced it with corresponding methods isAbstract(), isFinal(), and etc. Then, I would not have a minimal interface, but I would have proper encapsulation.

I'm not trying to respark the humane vs. minimal interface debate. But, I'm trying to point out that sometimes they can be at odds with one another. And when they are at odds, which one would you pick? Me? I will always pick encapsulation because objects should always hide their internal implementations.

I also brought this topic to show that by placing more value on a minimal interface. You sacrifice one of the most important attributes of object-oriented programming: encapsulation.

posted by Blaine at 12:59 PM |  0 comments |  Post a Comment