Showing posts with label OOP. Show all posts
Showing posts with label OOP. Show all posts

Monday, March 31, 2008

[Design Patterns] Butchering Design Patterns Part 1 - Open Door Pattern

Hi all,

this is the first post of the Butchering Design Patterns series. What we do here is try to highlight Design Patterns very common between butchers. Just like everyone, they often don't know they're using these patterns, they just go ahead with their unplanned coding and these patterns just emerge. Some of them make sense, some others do not, but after seeing them a number of times you may need to classify them.

Open Door - the Open Door Pattern is not particularly exciting but is very common between coding butchers.

Definition: define an abstract class declaring all your variable members as public, then implement a getter and setter for each of them. Define a concrete child class for your abstract class; when you need to set/get the variable member value, just use the first way that comes to your mind (access directly or through the getter/setter), or toss a coin if in doubt.

Frequency of use: very high

UML Diagram:
















Partecipants:
AbstractOpenDoor: declares an interface common to all concrete open doors.
ConcreteOpenDoor: inherits from abstract open door.

Code Sample:

// Open Door Pattern -- Structural example

using System;

namespace DotNetButchering.ButcheringPatterns.OpenDoor.Structural
{

// MainApp test application

class MainApp
{
const string scuffia = "Dirty Sanchez Lover";

static void Main()
{
ConcreteOpenDoor myOpenDoor = new ConcreteOpenDoor(0);

//It's good practice to use getter/setter
if (myOpenDoor.GetGenericMember() == 0)
myOpenDoor.SetGenericMember(1);

//...

//Now I am in a bit of a rush, I'll access directly
myOpenDoor.m_genericMember = 2;

//..

//I am not the butcher who developed this, and I'll probably never notice
//that m_genericMember is public
if(scuffia == "Dirty Sanchez Lover")
myOpenDoor.SetGenericMember(3);

//..

// Wait for user
Console.Read();
}
}

// "Abstract Open Door"

abstract class AbstractOpenDoor
{
public T m_genericMember;

public virtual T GetGenericMember()
{
return m_genericMember;
}

public virtual void SetGenericMember(T genericValue)
{
m_genericMember = genericValue;
}
}

//"Concrete Open Door"
class ConcreteOpenDoor: AbstractOpenDoor
{
public ConcreteOpenDoor(T initValue)
{
m_genericMember = initValue;
}

//whatever
}


That's all about the open door pattern. Keep in mind it is common to find it used without any abstract base.

Monday, February 11, 2008

[.Net, J2EE] A walk from J2EE to .NET: impressions and hopes

Last night, just before bed time, I was reading a book [reference] about Component Oriented Programming using .Net framework. Surely the introduction that resembles OOP against COP was interesting, but after few pages I asked myself: "What is .Net?"
Its nothing more than the same stuff as J2EE.

Since my degree, about 1 year and a half ago, I'm currently programming in JAVA, using all that kind of stuff that J2EE represents, such as JSP with its libraries, servlets, portlets, DB integration, web services, and so on.
I've never thought about .NET because I haven't needed it and my company uses to program in JAVA: why should I begin with .NET?

Actually in this year and a half I found myself in trouble with all J2EE technologies, what is a web service and how to use it, how to make a web server run and configure it, what a servelt is, which portlet containers should I use (starting without any knowledge of what a portal container is), which libraries supports XML handling, which supports other stuff, and so on: this is all understandable regarding my total ignorance of J2EE, but this multitude of libraries slows me down even now, and usually what I need is not documented as it should be.
So it seems J2EE is hard for newcomers that, like me, have not many live links with J2EE experts (I learned all alone with so little help), and even forums don't help (great tutorial for real noobs or too much in depth for the beginning!!).

Still now I'm on a project developed using portlets, web services and servlets, but yesterday I was thinking about what happened about 1 year ago.
One of my friends was about to do an inteview, and one of the tasks before the "personal" interview, was to implement a simple web service using .NET framework: even without any knwoledge of web services and what it's behind, I managed to accomplish that task (and my friend has been hired!)... I don't tell you what such a disaster has been my attempts in JAVA (I dominated them, but how hard!).

And now I think: the aim of every enterprise is to make profit, so what if I managed to accomplish the same task in half the time?
Reading a book about ASP.NET lend from a friend (a +1000 pages book, from the bases to the most advanced features [reference]), I succeed to understand all topics presented...I haven't implemented anything yet, but now I know .NET Framework makes things easier.
Its learning curve is faster, maybe you need a greater effort at the beginning: that's different in JAVA, infact coming from a general C/C++ knowledge and XML undestanding, you can easily implement a JSP that print out "Hello World!", but as you proceed on the road of J2EE consciousnees, things gets harder and harder.
Instead in .NET you need some time to orientate yourself about technologies used (the base language, C#, web services, web page layout creation, DBs, and so on), but as soon as you have enough knowledge of the framework, building an application will be straighforward.

And moreover, one of the greatest benefits of using JAVA is its portability and platform-indipendence, but I always programmed in Windows, using Microsoft ways of representing files, web servers configured in "windows-mode", so all efforts may have been useless, and learning .NET I would have found time to learn anything else, and increse productivity.

Ending, .NET and J2EE offers the same kind of malicious machineries and the first seems to be more programmer friendly.
I wonder if you, the reader, leaving away every "f**ck the system" ideology and open source nerdology , agree with me.
I just hope that I haven't wasted my time...
And so I ask: where do you think is the future of component programming?

Tuesday, January 29, 2008

Thinking in Generic

Hi Folks,
Can't wait to hear more about Generics and Templates fine-very-not-butchery feature of modern languages?
Well, sorry to disappoint you but you've got the wrong track (I'm not such expert of that, btw, raise their hand those who created their own class using generics in the last week).
I'm gonna talk instead of how people (even honest butchers like us) can try to be as generic as possible while designing their application.
I wanna introduce my personal thumb rule:
Don't make any assumption if noone will risk his goddamn neck without it.
It may sound like an easy one, but in my experience this is, in the 80% of bad designs I've seen, the main root cause.
Sometimes I've been asking around questions like:
  • "Why is that field of a so specific type ?"
  • "Why you DON'T need to have such information on your class?"
  • "Why these two classes do not have a common ancestor?"
  • "Why these properties do not belong to a super?"
Problem arises when the answer is: "I don't need that in my case" i.e., "I can assume this in my case".
Well, even a butcher like me could still ask you WHY?
OK, I've got it.
YOU think that you can make that assumption but, even if it's true (so far), why should you?
What is the catch? Saving manicure to your hands or 30 minutes from your work-clocking?
I've got it, you are saving those 30 minutes to beat Lou on Guitar Hero (yes I know you are a geek).
But, if you can't find any other reason to make those assumptions, you should just make to yourself (and to those who'll handle your design after you) a favour.
Don't make them.
And this is the reason why: there are very good chances in the air that you would be bitching yourself within a month (or that your colleagues will be bitching you) for that, believe me.
It's just an honest advice from a butcher, you don't think it's worthless right?
That's all for today, I've gotta finish writing some ugly (very butchery indeed) nested loops...

Thursday, September 20, 2007

Chop it!

The problem of butcheries is that people always look for the fastest way to find a solution. Planning, drawing and thinking is expensive. Butchering is not.
The following match summarize the dilemma of the butcher.
Have something working writing one single wrong line of code in the wrong place Vs Have something working redesigning the code (because something was forgotten when the code was designed the first time) to have an elegant and general solution to the problem.

Well you all know who will be the winner of the match in the butcher's mind.

The problem though is more complex than "laziness" the biggest problem is that the butcher often cannot go for the second solution for one of the following two reasons:

1) He's a butcher, butcher he was born and butcher he will always be. Not really gifted form mother nature the butcher understood since his first days the power of conditional instructions.
IF THEN ELSE...mmm...if this is this then this can be like that.....mmmm and if it's different...mmm ELSEIF! The butcher hardly resists IF temptations and ends up solving the 99% of his problems with an IF. The code at the end looks like a labyrinth. His real problem is that he does not understand designs and in his mind most of them are just hard-to-understand-solutions for problems that in his mind would only require two letters. IF.
OOP butchers are easily recognizable cause of the huge size of their classes. The truth is that butchers are nostalgic people who are missing the old PASCAL school. They create a class called MyApplication and put everything within it. Who said OOP was difficult?

2)The butcher is working in a butcher's shop so he has no way out. The code is chopped and minced as dead meat. He usually joined his company in the middle of the Butchers Summer Festival, the applications looks like a Dali's painting and he doesn't know where to start to tidy up the code. Hard to find an escape from such a place, the developer usually ends up sticking with company's polices.

Programming is an art, and noone could recognize a butchery without having been a butcher himself in the old times. The main problem I think is to catch the right problems. The 90% of butcheries born because of people ask the wrong question when they face a problem. When a developer ask himself the wrong question the wrong answer follows. The wrong answer is called CHOP IT. A lot of times I've heard questions "how to do this" where this was generally a particular something to have the application working in the punctual situation. Posing the question at the right level help people to avoid such situation. So my little advice if you feel like you are going to do a butchery is: ask yourself why you need that. Then ask yourself why you need that that needs the butchery and so on. Moving the problem far from the code minimize the risk of an inappropriate solution. This can't apply always of course but I find it useful in a good number of situations. I'll write more on this topic...Bye now.