Field = Attribute = Property = Getter = Method = Member. WTF?

When I started learning about Object Orientated (OO) programming some 15 years ago, I was taught a set of terms to describe aspects of OO: class, object, method and field. In recent years, I’ve added one more term to the list: property. Whilst in my own mind, these terms have clear meaning, such meaning is not universal. Continue reading “Field = Attribute = Property = Getter = Method = Member. WTF?”

Did we get OO Interfaces all wrong?

Recently I wrote an article on a suggested ActionScript language enhancement: implied interfaces. The idea was that, rather than having to explicitly define interfaces, they could be implied from public methods and properties of a class. This prompted a comment from someone just calling themselves “Toby” with a fascinating idea. In a nutshell that idea was: “why must we specify that a class implements an interface when it should be obvious to the compiler whether it does so or not.” Continue reading “Did we get OO Interfaces all wrong?”

Real world use-case of “use protected, not private”

evil-privateRecently I wrote an article that challenged the software accepted practice of hiding methods away using the private keyword. Instead I suggested that using protected is actually better practice. In this article, I present a real-world example of this philosophy whereby switching from private to protected makes it far easier to unit test one’s code Continue reading “Real world use-case of “use protected, not private””

AS3 static inheritance: developers beware! (revisited)

A while ago I wrote an article on the oddities of AS3 with regards to its lack of static inheritance. As part of my AS4 proposals series, I started writing a proposal for introducing static inheritance to AS4. In the process of writing it, I delved deeper into this topic and found that AS3 static inheritance is a truly strange beast indeed. It can be summed up neatly (though probably confusingly) as “for a class B that inherits from a class A, public static methods of A are inherited as protected static methods (which cannot be overridden) by class B” Continue reading “AS3 static inheritance: developers beware! (revisited)”

QCon day 1: Craftsmanship & functional languages

I had been somewhat apprehensive of the first day of this year’s QCon London as the schedule didn’t really excite me. The “Architectures You’ve Always Wondered About”, “Non-Relational DBs & Web Oriented Data ” and “Solution” tracks aren’t really my thing and the “Dev and Ops: A single team” and “Software Craftsmanship” tracks sounded like jargon-laden fluff tracks that were likely to be full of hot air and waffle, rather than substance. That left just the “Functional Programming” (FP) track. Whilst I’m happy to learn about FP, I didn’t want to spend my whole day on the one track. Thankfully, my worries were baseless and the day turned out to be really very good. Continue reading “QCon day 1: Craftsmanship & functional languages”

Adobe pay homage to failed development methodologies with WorkflowLab

waterfall methodThis week’s Adobe MAX event has seen a sizeable number of interesting and potentially exciting announcements and releases. One rotten apple stood out amongst these releases though.

As anyone who has been involved in software development over the last couple of decades will know, everyone once used to slavishly follow the waterfall method of software development. Projects were consistently late, over-budget and of poor quality. An endless succession of solutions to solving these problems were suggested, with little success. Then one day, the penny dropped and it was realised that the the waterfall method itself was to blame. It is a crap way of developing software; this is well recognised today. Instead of the design, implement, test, ship step approach to development, agile methods, such as Scrum, are growing in popularity. The reason is simple: agile methods are far more likely to deliver projects on time, in budget with a high quality value.

Given this, I was excited to see a work flow tool appear on Adobe Labs, called WorkflowLab and eagerly installed it to see what the tool would offer. To say I was disappointed would be a gross understatement. I was actually shocked by what I found.

The first – and relatively minor – problem was the poor user experience it offered me as a Windows 7 user. Rather than use the Windows chrome, the developers have opted to implement their own chrome. As a consequence, it lacks the nice drop shadow that “proper” windows applications have. It doesn’t support the new Windows 7 window resizing controls (ie dragging on the titlebar when maximised didn’t cause it to resume its non-maximised size). And it basically plain looks crap as it sits amid a sea of aero glass-decorated programs. My guess is that the developers use Macs and did no Windows 7 UX tests. As the latter has been freely available via the beta programme for months now, the developers have no excuse for this.

The second – and way more important –  problem can be observed in the screen shot below (click on it to see the full size image). What you see is a supposed “best practice” work flow for “InDesign to Kindle Store”.

WorkflowLab screenshot
WorkflowLab screenshot

The developers seem to seriously believe that completing the layout before previewing the result is “best practice”! And lest you think that this is a one-off, even the “Workflow Behind WorkflowLab” work flow show the classic design, develop, test, release waterfall approach and sells this too as “best practice”.

In case you haven’t worked it out by now, I strongly feel this is a rubbish application, full of bad work flow advice. By itself, this wouldn’t be too bad, but this is an Adobe-endorsed product that is supposed to sell the use of Flash Catalyst in the development work flow.  Catalyst has come in for criticism from some developers as the beta releases of the product only support one-way design -> develop work flows. I had assumed this due to it being a beta and that the final release would support circular, iterative, development. WorkflowLab opens up a worrying possibility though: that Catalyst will only ever support this one way flow, and Adobe are trying to con the world into thinking this is OK by presenting a failed work flow method as “best practice”.