All I wanted was a number

djork

Let's say our company writes software dealing in running a farmer's market, for anonymization purposes. You have farmers, farms, and stalls. The stalls at the market have numbers. Now let's say I want to go ahead and get the stall number for a particular individual farmer selling at this market. Considering these objects are all fairly common in our framework, you'd figure it would be a simple matter to get this number. No. After consulting with peers and spending a bit of time "engineering" a "solution" to this "business problem" the code looks like this (and yes, it's as simple as possible):

int FarmID = Farmer.FarmID;
if (FarmID != 0) {
	FarmController Controller = new FarmController();
	IFarm[] FarmList;
	IFarm SearchFarm = FarmersMarketClassFactory.CreateFarm();
	SearchFarm.FarmID = FarmID;
	Controller.SelectFarm(SearchFarm, out FarmList);
	if (FarmList != null && FarmList.Length > 0)
	{
		StallNumberTextBox.Text = FarmList[0].StallNumber;
	}
}

Could you make this any more enterprisey?

I certainly have had ideas on how to make this less enterprisey (Farmer.Farm.StallNumber properties, anyone?)... but I don't think I could go the opposite direction without a lot of effort.

djork

P.S. A few notes adding to the enterpriseyness of this code:

* There is only one concrete class that implements IFarm (as is the case with most interfaces in our framework)

* A single Farmer can only be associated with a single Farm, but we still need an out array to find it...

Saladin

@djork said:

* There is only one concrete class that implements IFarm (as is the case with most interfaces in our framework)

WTF? Why even have an interface then? O_o

RandomPoster

djork:

* There is only one concrete class that implements IFarm (as is the case with most interfaces in our framework)

WTF? Why even have an interface then? O_o

I don't think that is really a big deal, I do it quite often because I plan on expanding what I have already done... doing it now saves time for doing it in the future... I guess it all depends on how well you plan the system that you are writing. Now if they just created the Interface for the hell of it and have no plans on anything else ever implementing it, there is a wtf for you.

obediah

Wow, assuming this is just for a small local market, that's great. Certainly as big a wtf as the weekend hackjob of php and mysql it would have otherwise been.

I would have shot my enterprisey wad on supporting any situation where a "market" rents out space to vendors. That way I could sell to Farmer's Markets, fish markets, Swap Meets, shopping mall owners (for managing kiosks), and craft shops.

VGR

@Saladin said:

@djork said:
* There is only one concrete class that implements IFarm (as is the case with most interfaces in our framework)

WTF? Why even have an interface then? O_o

From what I can tell, it is a standard VB pattern. I don't know if Microsoft teaches it in their books/certification courses, or what. What I do know is that I frequently see VB people making an interface starting with an I (Hungarian Notation is TEH SUCK by the way) for every concrete class, and then using the interface as a parameter type but immediately casting the parameter to the concrete implementation of that interface inside the function. Pretty cargo-culty.

MasterPlanSoftware

@VGR said:

@Saladin said:
@djork said:
* There is only one concrete class that implements IFarm (as is the case with most interfaces in our framework)

WTF? Why even have an interface then? O_o

From what I can tell, it is a standard VB pattern. I don't know if Microsoft teaches it in their books/certification courses, or what. What I do know is that I frequently see VB people making an interface starting with an I (Hungarian Notation is TEH SUCK by the way) for every concrete class, and then using the interface as a parameter type but immediately casting the parameter to the concrete implementation of that interface inside the function. Pretty cargo-culty.

First, this is obviously not VB, It is most likely C#,

Second, yes this is a standard naming convention in the .NET framework. It is recommended programmers use the same convention in their architecture. This actually works out well since all interfaces are then grouped together in Intellisense (as an example). This doesn't really have much to do with Hungarian notation, since Microsoft has been trying for a while now to steer developers away from Hungarian notation. Also, since it is usually capitalized, it isn't actually hungarian notation anyway (all hungarian notation AFAIK is lowercase).

If you would like a little more enlightenment, http://en.wikipedia.org/wiki/Hungarian_notation

But please don't just start bashing VB (or Microsoft) when you lack the information to make a good argument.

As for the coding style... I don't know the full scale of the project, so I can't really comment on the WTFiness of this code, but yes it appears a little overdone.

@djork said:

Let's say our company writes software dealing in running a farmer's market, for anonymization purposes. You have farmers, farms, and stalls. The stalls at the market have numbers. Now let's say I want to go ahead and get the stall number for a particular individual farmer selling at this market. Considering these objects are all fairly common in our framework, you'd figure it would be a simple matter to get this number. No. After consulting with peers and spending a bit of time "engineering" a "solution" to this "business problem" the code looks like this (and yes, it's as simple as possible):
int FarmID = Farmer.FarmID;
if (FarmID != 0) {
	FarmController Controller = new FarmController();
	IFarm[] FarmList;
	IFarm SearchFarm = FarmersMarketClassFactory.CreateFarm();
	SearchFarm.FarmID = FarmID;
	Controller.SelectFarm(SearchFarm, out FarmList);
	if (FarmList != null && FarmList.Length > 0)
	{
		StallNumberTextBox.Text = FarmList[0].StallNumber;
	}
}
Could you make this any more enterprisey?

I certainly have had ideas on how to make this less enterprisey (Farmer.Farm.StallNumber properties, anyone?)... but I don't think I could go the opposite direction without a lot of effort.

I don't think farmer.farm.stallNumber makes any sense. A farmer has farms. A farmer has stall numbers at the market. Farmers don't know about all other farmers. Farmers do not determine which stall they are assigned. Therefore a StallController is queried to find out which stall a farmer is given.

jminkler

@djork said:

Let's say our company writes software dealing in running a farmer's market, for anonymization purposes. You have farmers, farms, and stalls. The stalls at the market have numbers. Now let's say I want to go ahead and get the stall number for a particular individual farmer selling at this market. Considering these objects are all fairly common in our framework, you'd figure it would be a simple matter to get this number. No. After consulting with peers and spending a bit of time "engineering" a "solution" to this "business problem" the code looks like this (and yes, it's as simple as possible):
int FarmID = Farmer.FarmID;

if (FarmID != 0) {

FarmController Controller = new FarmController();

IFarm[] FarmList;

IFarm SearchFarm = FarmersMarketClassFactory.CreateFarm();

SearchFarm.FarmID = FarmID;

Controller.SelectFarm(SearchFarm, out FarmList);

if (FarmList != null && FarmList.Length > 0)

{

StallNumberTextBox.Text = FarmList[0].StallNumber;

}

}
Could you make this any more enterprisey?

I certainly have had ideas on how to make this less enterprisey (Farmer.Farm.StallNumber properties, anyone?)... but I don't think I could go the opposite direction without a lot of effort.

Somewhere you have fallen off the road of good intentions, if you are running a farmers market you have a market of stalls, each stall is asigned to a farm, who has a farmer. Not sure why you would check if the length is greater than 0 then only return the first element, this lets bugs hide out undetected. Then you have GUI mixed in with logic, never very swift ... A factory should be assigning the stall ID to the farms when it creates them and I beleve you are creating a blank farm setting its farm ID and then pass it to a controller, which sends the same thing back to the FarmList. You are tyring to find the stall given the Farmers ID that's it, this value should be passed back not set to a text box value. It could be something as simple as

Enumeration/Iterator marketList = Market.enumeration/list/etc

while(marketList.has some more items) {

get the stall's Farm

get the Farm's Farmer ID

if(found) return that ID

}

of course ... this should most liekly jsut be SQL

SELECT Stall_id from Stall, Farm, Farmer WHERE Farmer.ID = FarmerID and Farmer.FarmID = Farm.FarmID AND Farm.ID = Stall.FarmID