Encapsulation -v- Component Design

[lightng]

And before 2001 what did you do?

Sounds like you might be promoting the 'plenty quickness, much cheapness' variety of OOP.

If you've being doing C# development since 2001 and you still fail to grasp the relevance of encapsulation and inheritance then I suggest you find alternative employment.

As for you boss, what does some old C/C++ dude know?

GRASP is an apt word. Solent, google "GRASP and OO". It's the basis for your bosses logic and makes great sense.

[bogeyman]

I'm a C# developer since PDC 2001

And before 2001 what did you do?

Sounds like you might be promoting the 'plenty quickness, much cheapness' variety of OOP.

If you've being doing C# development since 2001 and you still fail to grasp the relevance of encapsulation and inheritance then I suggest you find alternative employment.

As for you boss, what does some old C/C++ dude know?

[pmeswani]

Something for the .net programmers out there. I guess this is a top level question... As you maybe some of you have read, I am going through an issue with quality of code etc.

My boss has delivered some code today / this morning which I cannot understand his logic. I'm a C# developer since PDC 2001 and he's from a from a C / C++ background. Everything to him he has to box as an Object, I'm still standing my ground and yes... there has to be a certain amount of encapsulation but not to the degree where code is unmanageable and you have to 'Go To Definition' in VS on several layers to understand what its doing. Surely we have an object but its Component Design now, albeit it's based on a Base Class. Finding it frustrating now. Segregate objects !

As an academic learner of OOP, I am siding with your boss here. Encapsulation is needed, no matter how deep. If the problem is with documentation, then take it up with your boss... Don't argue with him about the need to encapsulate.

[jkoder]

Something for the .net programmers out there. I guess this is a top level question... As you maybe some of you have read, I am going through an issue with quality of code etc.

My boss has delivered some code today / this morning which I cannot understand his logic. I'm a C# developer since PDC 2001 and he's from a from a C / C++ background. Everything to him he has to box as an Object, I'm still standing my ground and yes... there has to be a certain amount of encapsulation but not to the degree where code is unmanageable and you have to 'Go To Definition' in VS on several layers to understand what its doing. Surely we have an object but its Component Design now, albeit it's based on a Base Class. Finding it frustrating now. Segregate objects !

I don't want to sound offensive but if you have around 7/8 years experience in C# the penny should have dropped by now. Not to mention that you can't read a book or article on the internet where they don't use the approach outlined by your boss, it's not an OO language for nothing. As pointed out this code should come with documentation so you can see the public interfaces and relationships between objects.

[Shimano105]

WTS

I am a recent escapee from VB6 land and I have to say that the encapsulation approach is a no brainer.

I don't mean to be obnoxious here but you actually sound like a VB6er who understands basic compositional objects but not inheritance.

[Cowboy Bob]

I'm with your boss and Bogeyman, the whole point of OO is to encapsulate data and logic. I bet you're one of those annoying people who make member variables public because you can't be bothered to write getters and setters.

[bogeyman]

Sorry. I think I have to side with your boss here.

Whatever you think of his code, his concept is right.

An object should be a black box. It should have well documented public interfaces, but what goes on inside the box is, to you, as a consumer of the object, none of your business.

You imply that your boss's class is derived from a base class, so it should exhibit all of the properties and methods of that base class. Issues should only arise when your boss's class offers additional properties or methods, or overrides the properties or methods of the base class. If these additions are poorly worked, or badly documented, then you have a problem.

Whatever issues you have with your boss's class, they wont be solved by snooping around in its internals.

Talk about missing the point of OOP!

This is in no way .net specific, incidently.

[Solent]

Something for the .net programmers out there. I guess this is a top level question... As you maybe some of you have read, I am going through an issue with quality of code etc.

My boss has delivered some code today / this morning which I cannot understand his logic. I'm a C# developer since PDC 2001 and he's from a from a C / C++ background. Everything to him he has to box as an Object, I'm still standing my ground and yes... there has to be a certain amount of encapsulation but not to the degree where code is unmanageable and you have to 'Go To Definition' in VS on several layers to understand what its doing. Surely we have an object but its Component Design now, albeit it's based on a Base Class. Finding it frustrating now. Segregate objects !