OK, new year, old life, and very poor free time for posting or enjoying a lot of new technologies waiting for me and requesting my attention!!!!
I should find more time .... no, correct myself .... I MUST find more time!!!!
Repeat, please : more time, more time, more time ..... !!!!
However, I don't want to talk about this, but rather about what happened to me some days ago: in fact, last week I started my first, true, teaching experience.
I started teaching Object Oriented Design & Programming in Java to a class of eight: I am very passionate about object oriented design and I totally devoted myself in communicating them OO principles, achieving also good results.
The eight would-be OO Java developers had all a strong Visual Basic 6.0 background, and what mostly surprised me was how many bad habits this sort of programming language embed in whoever is exposed to it for a lapse of time greater than, say, one year.
Visual Basic literally destroyed a generation of programmers.
Moreover, I truly discovered how difficult is to move from procedural way of thinking, to object oriented one, and how difficult is to solve a problem in object oriented fashion.
However, this should not surprise myself, because I know a lot of developers who, while using Java or C++, don't really develop in OO and maybe don't fully understand it.
I think that object oriented design (and programming) is one of that things which everyone theorically praise but practically (almost) never do.
And this is very bad, and this is the reason why many projects literally go spaghetti.
This is why I'm starting to love Domain-Driven Design .... but this is another story.
Which maybe I will tell you some day.
14 comments:
I would love to discuss OO heuristics and DDD. I am a fan of both but find them often in conflict.
For a simple example… In DDD we create domain/business objects that do not concern themselves with storage, just their business. Very OO in that it abstracts a single concept. I like that idea. My business objects don't concern themselves with databases and the like, it’s not their business. However, in the business applications I write we often have to store data related to business objects. In order to do this, the business objects have to expose their data to the objects that handle storage. Very, very un-OO as encapsulation is lost.
I would love another competent developers take on these issues and non-language specific discussion on resolving these things.
-Joe Reddy
http://swcses.eponym.com/
> in the business applications I write
> we
> often have to store data related to
> business objects. In order to do this,
> the business objects have to expose
> their data to the objects that handle
> storage. Very, very un-OO as
> encapsulation is lost.
Hi Joe,
as I already said in other posts, there are several ways for avoiding this kind of information leaking: in particular, the use of interfaces, and the use of AOP.
What do you think?
Cheers,
Sergio B.
I am a big fan of the book, “Writing Solid Code” by Steve Maguire. He makes excellent points about best practices that should be carried on regardless of language and almost regardless of situation. One of my favorite points he makes is to write code for the average developer. For me using an AOP framework makes my application that much harder for “the next guy” to understand, can make bugs hard to find, etc. etc. Now I understand that “average” is relative but if I always consider my self a little better than average than I have a good idea for whom I am coding for. So unless I find this absolutely necessary…I will refrain from using AOP.
One of the problems with teaching software concepts is making a design choice obviously useful. (I’m sure you know this more than most) It is easy to explain to someone the idea of encapsulation and even explain the benefits. However, without a good example that the person can relate to it all becomes philosophical fluff. When the person gets out in the real world they can’t apply what they’ve learned. What makes this more difficult is that what you relate to, I may not so one example is rarely enough.
I use interfaces as you may well expect. However, their most useful purpose to me has been polymorphism. Code A does FunctionA. FunctionA takes in any object that implements the Coordinates interface as an argument. It is coded to the interface, not a class. I have gotten so used to that example and usefulness that I almost define interfaces in that light. Shame on me eh!? Your example in the previous post made me kick myself. Of course that is better than my current solution which relies on convention: Developers just “know” they should not be accessing the “data” properties of an object. Yuck.
I like this solution better because an average OO developer should understand interfaces, even if they were not being put to use in this way before. No new terms are introduced, this is just another way of looking at things.
Thanks for your time. I will be discussing this with other members of my team to see how this looks to them. It is not perfect, but it is way better than what I was doing.
-Joe
Ahhhhh, we have found a draw back to the interface idea. Maybe you can tell us where we are going wrong, or if this just is a mild drawback only to be noted.
Imagine this scenario…
A user interface has a list box of CarOwners. Each CarOwner object is actually an object implementing the ICarOwnerBO interface. The user chooses one of these and then makes a call to get all Cars the CarOwner owns. This call will have to take in an ICarOwner and then cast it as ICarOwnerData to get to the database properties necessary to query the database for this info. Ouch…I said cast….a bad design smell as it can create runtime errors.
Thoughts?
-Joe
I meant "This call will have to take in an ICarOwnerBO "
Oops, I meant "This call will have to take in an ICarOwnerBO"
Speaking of interfaces...
Oops this blogger interface is acting flaky today!
> For me using an AOP framework makes my
> application that much harder for “the
> next guy” to understand, can make bugs
> hard to find, etc. etc. Now I
> understand
> that “average” is relative but if I
> always consider my self a little
> better
> than average than I have a good idea
> for
> whom I am coding for. So unless I find
> this absolutely necessary…I will
> refrain
> from using AOP
I fully understand your doubts, but if you always take decisions with average developers in mind, you'll probably never get a chance to improve your knowledge and skill, and discover new things that could make you write better software ... like AOP (if correclty used).
> Your example in the previous post
> made me kick myself.
Yes, many developers think at interfaces just as a way of enabling polymorphism: it is not so, because they are also a protocol between objects, defining what methods an object can expose to others, and waht methods can not.
Cheers!
Sergio B.
> we have found a draw back to the
> interface idea
> [CUT]
> This call will have to take in an
> ICarOwner and then cast it as
> ICarOwnerData to get to the database
> properties necessary to query the
> database for this info. Ouch…I said
> cast…a bad design smell
Why do you have to make that cast?
What do you mean when saying that you need to access some properties for querying the database?
Maybe a concrete example could help.
Cheers!
Sergio B.
Doh! That was my concrete example. ;-)
On the UI the code should only see the business interface to a class. So when the UI asks for a collection of CarOwners, it really gets a collection of ICarOwnerBOs - the business interface to the car owner class. One is chosen and the UI wants to list the cars the car owner has. A call is made to (I think in the DDD world a repository) get the Cars owner by a car owner. This method call will require an ICarOwner becuase that's what the UI has. When it gets the ICarOwner it will not be able to access CarOwners data properties...like say a CarOwner ID. The only way to get at this would be to A)cast as a CCarOwner and read the property B) cast as another interface that allows access to the databased properties or C) create a database key object that is exposed thought he ICarOwnerBO interface but then I have lost something.
I'm sorry if this is unclear, I am may be assuming something that is common knowledge to me about how we write software, or something.
It boils down to someone (code) using the business interface of an object and then needing to get to more objects that will have to come from a database, thus requiring data of the object not exposed through the business interface.
Currently on the DDD yahoo group they are stating that business objects should not talk to repositories. They site testability reasons and the like. However, to me a simple solution to my problem is to have the business interface provide a method called something like CarOwner.GetCars() behind the scenes it would make the call to the repository.
[but if you always take decisions with average developers in mind, you'll probably never get a chance to improve your knowledge and skill]
Don't get me wrong, I did not say never, however I am very wary of accidental complexity. This can be as simple as a developer changing three clear lines of code into one "elegant" line of code because they learned some obscure language syntax. Uggh. Or as complex as applying a GOF pattern when the complexity added did not buy much in terms of what we might care about in the situation. There is a time and place for everything, however I find many developers learn some cool new concept and then apply it blindly. In other words, they don’t take into account the drawbacks.
When I Googled AOP to reacquaint myself with some of its intricacies, I found 2 out of 3 pages were condemning it for its complexities, etc. Then I remembered why we left it alone after our last investigation in to it. I would have to be convinced the problem is bad enough to entangle my software with it.
Good points, thanks for the discussion!
> When it gets the ICarOwner it will not
> be able to access CarOwners data
> properties...like say a CarOwner ID.
> The
> only way to get at this would be to
> A)cast as a CCarOwner and read the
> property B) cast as another interface
> that allows access to the databased
> properties or C) create a database key
> object that is exposed thought he
> ICarOwnerBO interface but then I have
> lost something.
Ok, now I get your point.
I have to say that I rarely have your needs because the frameworks I use for my web layer have always built-in binding features capable of accessing properties by reflection.
However, you can do the following:
Step 1 - Given your ICarOwnerBO business only interface, code an ICarOwnerView interface exposing accessor methods needed by the web layer (those for what you call "database properties").
Step 2 - Code your web layer against the ICarOwnerView: doing so, your web layer will be able to access al db properties you need.
Step 3 - Code your application service layer against the ICarOwnerBO: doing so, your service layer will be able to access al business methods you need, and no unwanted properties.
Step 4 - Given your CarOwnerImpl, implementing your ICarOwnerBO interface, let it implement your ICarOwnerView interface too.
Step 5 - Code a kind of repository object that will return ICarOwnerView (to be called by the web layer) or ICarOwnerBO (to be called by the service layer) objects: please note that in both cases the repository will return a single CarOwnerImpl, but with different interfaces!
So you have no duplicate implementations: just one concrete object and two interfaces.
Let me know if it helps.
Cheers,
Sergio B.
[Let me know if it helps.]
Heck yeah it helps! We all get stuck in our own little programming worlds either by ourselves or even with a team. It is hugely beneficial to see how people in other situations are writing code.
It can be very difficult to discuss these things because we both make many assumptions about how the other person might be doing things. And the fact that you are sleeping when I am awake and vice versa makes it interesting too.
We have been playing around with three views of the object by way of two interfaces.
One is a public EditView interface used by admin user interfaces that have to see and deal with almost every property of an object. It has no methods unless directly related to changing or creating data for an object…so maybe validation methods. We have a second BusinessView interface that is used by any code that needs to do some work with the objects. The final view is just access to the object itself. This is only used by (what I think you would call) repositories and factories. However, we are still just playing around to see what works best for us.
I also have to comment on this…
“Visual Basic literally destroyed a generation of programmers”
Well I write in VB and I think it is the greatest language ever…..OK I’m kidding!
You crack me up! There is a lot of truth in what you said. I worked with VB for a while but was embarrassed by the community of developers. Granted there are some great developers using VB, but I don’t think they outnumber the poor ones. I don’t know how much of my blog you skimmed through, but my “Top 10 signs of a code writing hack” is almost directly connected to my experience with many Visual Basic developers. Please look over it and see what you think. See how many of the signs match the VB students your are working with. Please share with me anymore “signs” you think of or any disagreements you might have.
Here’s the link to my article on the Top Ten Signs of a Code writing hack.
Thanks again for your time,
-Joe
Oops, the link did not paste over. I'll try again...
Top 10 signs of a code writing hack
Post a Comment