Design and Architecture

15-Apr-11 8:19

According to http://www.oodesign.com/design-principles.html, http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445 should have some

DRY

Member 448708313-Apr-11 8:45

Member 4487083

13-Apr-11 8:45

Code duplication really frustrates me. Is it just me, or do others feel the same? What I'm thinking about is when somebody has clearly copied a chunk of code, and then changed a few lines in the new version. Duplication seems to always cause problems.

Some people just don't seem to see the problems though. They will copy code without thinking about it, and give you a puzzled look when you say something about it. It always seems to be somebody else who either has to suffer or spend time refactoring it. In my opinion it's just a 'hack'.

Pete O'Hanlon13-Apr-11 9:09

13-Apr-11 9:09

Member 4487083 wrote:
Is it just me, or do others feel the same? What I'm thinking about is when
somebody has clearly copied a chunk of code, and then changed a few lines in the
new version. Duplication seems to always cause problems.

It really depends what you're talking about. DRY just means don't repeat yourself. If the code you've taken is from the web, then modifying it to suit your needs is perfectly acceptable. I do agree that it's a PITA when somebody copies and modifies code that they don't understand (we see plenty of that in the forums).

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

Member 448708313-Apr-11 9:34

Member 4487083

13-Apr-11 9:34

Pete O'Hanlon wrote:
It really depends what you're talking about. DRY just means don't repeat
yourself. If the code you've taken is from the web, then modifying it to suit
your needs is perfectly acceptable. I do agree that it's a PITA when somebody
copies and modifies code that they don't understand (we see plenty of that in
the forums).

Copying snippets from the web is usually ok. Although I would expect somebody to copy a block of code from the web and paste it in many places. Unless it's a simple, single line of code then it should probably go into something like a function/method. I don't think I've seen cases where people don't understand the code that they copy, but I'm sure it happens.

Pete O'Hanlon13-Apr-11 9:51

13-Apr-11 9:51

Member 4487083 wrote:
I don't think I've seen cases where people don't understand the code that they
copy, but I'm sure it happens.

You obviously don't spend a lot of time answering questions in the forums here then.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

Eddy Vluggen13-Apr-11 10:25

Eddy Vluggen

13-Apr-11 10:25

Pete O'Hanlon wrote:
It really depends what you're talking about. <layer>DRY just means don't repeat yourself. If the code you've taken is from the web, then modifying it to suit your needs is perfectly acceptable. I do agree that it's a PITA when somebody copies and modifies code that they don't understand (we see plenty of that in the forums).

In that case, you're repeating someone else. Having the same method repeated in your project would be a duplication, giving you two places to maintain that offer similar functionality.

I are Troll Suspicious | :suss:

Pete O'Hanlon13-Apr-11 10:30

13-Apr-11 10:30

I know what DRY means. I was just clarifying it because the wording could have been taken that way.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

Eddy Vluggen13-Apr-11 12:11

Eddy Vluggen

13-Apr-11 12:11

No offence meant, sorry Smile | :)

Pete O'Hanlon14-Apr-11 4:04

14-Apr-11 4:04

None taken. I thought I'd better put my reasoning there why I clarified.

I'm not a stalker, I just know things. Oh by the way, you're out of milk.

Forgive your enemies - it messes with their heads

Eddy Vluggen13-Apr-11 10:19

Eddy Vluggen

13-Apr-11 10:19

Amen.

RobCroll15-Apr-11 18:55

RobCroll

15-Apr-11 18:55

It happens a lot when the KPI is the number of tasks completed. When you see someone doing it all the time and their KPI and wage is twice that of anyone else, you got to ask yourself is DRY worth the cost to you personally.

"You get that on the big jobs."

Member 448708315-Apr-11 22:52

Member 4487083

15-Apr-11 22:52

RobCroll wrote:
It happens a lot when the KPI is the number of tasks completed. When you see
someone doing it all the time and their KPI and wage is twice that of anyone
else

That's a very interesting point, I don't know whether our KPI's are based on the number of tasks completed. There certainly are times where people seem to checkin bad code, and are unable to explain why they did it. However, I don't think the management would have a rule like this. They are trying to improve the code quality, although there is always a drive to get work done quickly.

RobCroll wrote:
you got to ask yourself is DRY worth the cost to you personally

Well, I suppose you need to decide what is most important to you. Do we want to be software developers or hackers? We spend a lot of our life working, so I want to make sure that I enjoy my work. However, if you're in a company that has bad KPI's then it's probably best to find a company that doesn't. I think it's probably hard to find a company with a good development team though Frown | :(

I'm a developer because I enjoy developing software. It's becoming more difficult for me to enjoy it when I know that the code is full of rubbish. I sometimes think that a management/teamleader position would be a better place for me because I could have some influence over the quality without actually having to work with the rubbish. Maybe small companies (with a one or two man team) are the way forward.

How do you specify states? State Pattern, Enums or ...?

GParkings2-Sep-11 2:17

GParkings

2-Sep-11 2:17

I am an almost religious advocate of the DRY principle (I have broken it a few times but either through extreme need or the decision wasn't mine to make.. and believe me, in that case, i fought it bitterly)

In my experience, there are a LOT of developers out there happy to throw the DRY principle away and they cite the following excuses:

- Time constraints
- Budget constraints
- Too high impact on existing (flawed) design
- Inexperience (excuse usually given by someone else on their behalf)

Personally i find i generally design a system in my head, then as I'm coding it spot areas where I'm in danger of breaching the DRY principle and, in rooting these out, a better design surfaces.

I guess there are two types of developer, the first measures their success in designing and building an application by the elegance of the end design and its adherence to good coding practice, the second measures their success by meeting performance targets.

I have worked in environments where some developers were bringing in unmaintainable messes early and under budget and were praised by the PHBs as examples for the rest of us coders (scraping by the budgets with elegant solutions)

Sloppy coding can give you a short-term gain, but its gonna bite you in the arse eventually

IsRanting = false; Poke tongue | ;-P

Keld Ølykke11-Apr-11 8:49

Re: How do you specify states? State Pattern, Enums or ...?

11-Apr-11 8:49

I'd like to gain an overview of the whens and whys about state specifications/implementations.

How do you go OOP when specifying states? Or do you prefer an enum? ints? ...

References are also appreciated.

I am very mixed about this topic, so you will get no religious opinions from here.

Thanks!

Keld Ølykke

RobCroll15-Apr-11 19:04

RobCroll

15-Apr-11 19:04

I'll go for enum over int every time because there probably isn't going to be billions of states and by strongly typing the values, it makes the design a lot more robust and maintainable. MyState.Enabled as opposed to 1 is a lot easier to work with.

"You get that on the big jobs."

Re: How do you specify states? State Pattern, Enums or ...?

Keld Ølykke24-May-11 2:28

Setup global settings with abstract class and reflection to avoid xml configuration file

24-May-11 2:28

Thx

Kannan Ar25-Mar-11 18:33

Kannan Ar

25-Mar-11 18:33

Hi All,

I am developing a library component which requires some global settings. Personally I don’t like to maintain an xml configuration file for this.

An idea strikes for me that to write an abstract class with an abstract method which can override and set global setting by the implementers of this library.

The abstract class will look like something like this.

public abstract class LibSetting
{
     public int MaxCount { get; set; }

     public abstract void SetCount();
}

The end users will implement this abstract class in their application is as follows.

public class MySetting : LibSetting
{
    public override void SetCount()
    {
        MaxCount = 100;
    }
}

To get the end user setting from my library, I am using following code.

public int ShowCount()
{
       Assembly asm = Assembly.GetCallingAssembly();

       IEnumerable<Type> types = asm.GetTypes().Where(t => t.IsClass && t.BaseType == typeof(LibSetting));

       LibSetting setting =(LibSetting) asm.CreateInstance(types.First().FullName);

       setting.SetCount();

       return setting.MaxCount;
}

This will work perfectly. My doubt is that, is it feasible in architecture level of view? I think the performance of read an xml file and loading a class using reflection would be same ( I didn’t test it). So is this a good practice? Kindly advice me on this.

Thanks and Regards,
Kannan

Re: Setup global settings with abstract class and reflection to avoid xml configuration file

Keld Ølykke4-Apr-11 12:17