Weblogs Forum - OOP Case Study: The Bank Account Class (Part 3)

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
OOP Case Study: The Bank Account Class (Part 3)

19 replies on 2 pages. Most recent reply: Nov 27, 2004 2:19 PM by Michael Feathers

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 19 replies on 2 pages [ « | 1 2 ]

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: OOP Case Study: The Bank Account Class (Part 3)

Posted: Nov 20, 2004 7:47 AM

> From what I have seen so far, it appears that the
> problem lies not in lack of features in the languages
> used, but rather ineffectual use of abstraction in
> code.
>
> Yup. The use of mocks requires not only sensible
> abstraction but decoupled objects too. Michael Feather's
> blog wanted to be able to instantiate any class regardless
> of the dependencies - a difficult problem to be sure!
>
> One way I've found which makes mocking easy is the wide
> use of interface classes. You touch on this here, too.
>
> What you describe at the end is what I know as
> "paramaterise from above", another way to reduce
> dependencies. You "parameterise" with a generic type. In
> this example, however, I think I'd have an interface class
> for the logging type, and pass that to the account.
>
> interface ILog
> {
> }
>
> class Account : IAccount
> {
> Account( ILog log );
> }

There's another little trick that you can use that I call Extract Implementer.

Suppose you have a Log class that is used by an Account class. Rather than creating an ILog interface, you can create a subclass of Log named ProductionLog (or something along those lines), push down all of the implementation in the Log class into ProductionLog and then turn Log into an interface that ProductionLog implements.

When you do that, you can avoid the cascading change that often happens when you introduce an interface, and you end up getting more abstraction all the way across the code base without having to change type names. The only downside is that you have to change Log to ProductionLog in the places where you create objects.

I use this trick often in C++ to compensate for the lack of a good refactoring tool with Extract Interface support, but it often comes in handy in languages with tool support too.

Steve Love

Posts: 20
Nickname: essennell
Registered: Sep, 2004

Re: OOP Case Study: The Bank Account Class (Part 3)

Posted: Nov 20, 2004 8:54 AM

> Steve, thanks. In the blog entry that Chris quoted I was
> talking about adding first class support for testing in
> languages. The idea was that tests could have special
> access to classes to allow easy mocking without affecting
> the encapsulation of the code in production.

Yes. A re-reading (in the light of this reply) made this more clear to me.

> I'm all for teaching people how to design better and
> helping organizations alter their development so that they
> aren't continually under the gun. It is what I do for a
> living. But, to me, it is only half of what needs to be
> done.

Part of the problem is telling people they have a problem - without them running off in a sulk :-) - the so-called Not Invented Here syndrome. I'm not a consultant and so only see this side from the jobbing programmer's perspective, which causes me enough grief. And it's still only those programmers (or shops) who care enough that will use the techniques you mention or imply anyway. Sadly.

Maybe I'm getting too jaded from being frustrated in trying to improve my own lot %-)

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: OOP Case Study: The Bank Account Class (Part 3)

Posted: Nov 20, 2004 9:32 AM

>
> Part of the problem is telling people they have a problem
> - without them running off in a sulk :-) - the so-called
> Not Invented Here syndrome. I'm not a consultant and so
> only see this side from the jobbing programmer's
> perspective, which causes me enough grief. And it's still
> only those programmers (or shops) who care enough that
> will use the techniques you mention or imply anyway.
> Sadly.
>
> Maybe I'm getting too jaded from being frustrated in
> trying to improve my own lot %-)

This post touches a nerve with me, because I am the target of frequent criticisms for my work on Heron, and my radical ideas on C++. This post is by no means directed at Steve, nor anyone in particular, but I do want to get it off my chest.

I think that a related problem is that every single developer with a few years under the belt thinks they are an expert! This is infuriating. There are two sides to the "telling it like it is". The other side of the coin is that some people who believe they are experts and feel compelled to tell others why they are wrong, even though they may lack the neccessary experience, intelligence or education, to deeply understand what is occuring.

As a case in point I often hearing people disrespecting truly great computer scientists like Bjarne Stroustrup, or Bertrand Meyers because they simply lack the tools for appreciating their genius.

Like I said, I am not implying that Steve doesn't run frequently into novices, or people with really poor approaches. I am in full agreement that the industry has a glut of miseducated (or uneducated) hacks.

Perhaps with time, the quality and consistency of the education of software developers will improve, and standards will raise, so that we won't have so many hacks working in software development and not experts will be fewer and more easily identified.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: OOP Case Study: The Bank Account Class (Part 3)

Posted: Nov 27, 2004 2:07 PM

> > I'm all for teaching people how to design better and
> > helping organizations alter their development so that
> they
> > aren't continually under the gun. It is what I do for
> a
> > living. But, to me, it is only half of what needs to be
> > done.
>
> Part of the problem is telling people they have a problem
> - without them running off in a sulk :-) - the so-called
> Not Invented Here syndrome. I'm not a consultant and so
> only see this side from the jobbing programmer's
> perspective, which causes me enough grief. And it's still
> only those programmers (or shops) who care enough that
> will use the techniques you mention or imply anyway.
> Sadly.
>
> Maybe I'm getting too jaded from being frustrated in
> trying to improve my own lot %-)

It takes a lot of subtlety. When you are working peer to peer, don't tell people they have a problem, help them discover the problem. The only "in" I've ever found is connecting with them at the level of "what is cool about programming." If you can, you can share experiences and build trust. If you can't, it's time to walk away until you can.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: OOP Case Study: The Bank Account Class (Part 3)

Posted: Nov 27, 2004 2:19 PM

> > Maybe I'm getting too jaded from being frustrated in
> > trying to improve my own lot %-)
>
> This post touches a nerve with me, because I am the target
> of frequent criticisms for my work on Heron, and my
> radical ideas on C++. This post is by no means directed at
> Steve, nor anyone in particular, but I do want to get it
> off my chest.
>
> I think that a related problem is that every single
> developer with a few years under the belt thinks they are
> an expert! This is infuriating. There are two sides to the
> "telling it like it is". The other side of the coin is
> that some people who believe they are experts and feel
> compelled to tell others why they are wrong, even though
> they may lack the neccessary experience, intelligence or
> education, to deeply understand what is occuring.
>
> As a case in point I often hearing people disrespecting
> truly great computer scientists like Bjarne Stroustrup, or
> Bertrand Meyers because they simply lack the tools for
> appreciating their genius.
>
> Like I said, I am not implying that Steve doesn't run
> frequently into novices, or people with really poor
> approaches. I am in full agreement that the industry has a
> glut of miseducated (or uneducated) hacks.
>
> Perhaps with time, the quality and consistency of the
> education of software developers will improve, and
> standards will raise, so that we won't have so many hacks
> working in software development and not experts will be
> fewer and more easily identified.

It could happen, but I suspect that it won't because there really isn't a programming community; there are really a bunch of somewhat disjoint programming communities.

There are the MIT Lisp hackers, the mainframe programmers, disaffected post-boom Java programmers, engineers w/Fortran, insular VB programmers, the Smalltalk community, seasoned C++ programmers, the list goes on and on... and they all look at the elephant from a different perspective.

For instance, I spent about ten years using C++ as my primary language before I really started to working with people from the Smalltalk community. At that point, began to realize how much C++ had biased my perspective.

Everyone brings a different view to the table. Personally, I like working with people who see themselves as experts more than people who don't care. At least there is the chance to connect on technical matters and move forward, provided ego doesn't get in the way.

Flat View: This topic has 19 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic


	Web Artima.com