Two questions: Interface and Encapulation

Woops, I didn'tsee the "Answer" button and I posted a comment, So here it is again in an answer.

Perhaps post the entire class and state exactly what it is that you're trying to accomplish. However (mile-high view): 1) First off, use properties for data. This way you can utilize databinding. 2) If your intention is to create some form of data type then take a break and think of the String class and how it's implemented. It has several methods (albeit mostly static) that maintain it's state. It has properties like Length that return the length. It's absolutely ok for your class to return Binary and Hex sequences based on the current state of it's properties, and to throw exceptions when it's state would be comprimised when setting a prooperty. You mentioned that the "interface" may change.I didn't see an interface in your example so I can't advise any more until I understand the problem domain and see the entire class definiton. Mike --- Michael Lopez  1 sec ago  delete

Great reply by Pradip.

Additionally, yes, interface has this slight thin line with respect to things getting changed.  Ideally, when you plan on using interfaces, we need the API to planned and given deep thought as changes in the interface has cascading effect on the subsystems.

Generally, I don't prefer interfaces with only properties, with some exceptions
- If I am using an MVP pattern for my UI architecture, then I tend to create properties in interface (still has issue, when a new view element is introduced, the interface changes)
- There are other scenarios, but I would like to keep interfaces very small and tight.

I usually prefer abstract base classes, where things are pretty dynamic and changes are frequent.   Though in theory, there may be some negative points with respect to the approach, but, in a practical world things are not that simple.  Things are not that fixed and static.  Things change, contracts change or evolve over a period of time etc.

To avoid breaking OCP, your interface should be minimal and fixed.  Alternatively think about composition.  But somewhere again there is a thin line between the abstractions required.

Note, OCP works great if the underlying interface is well defined, otherwise, there is something wrong in the design or there is lack of thought put into design.

Interface should be small and cohesive and should have very little reason to change.

Here's a good discussion on abstract base classes vs interfaces...
http://haacked.com/archive/2008/02/20/versioning-issues-with-abstract-base-classes-and-interfaces.aspx


Please note you can bring .net dynamic objects into picture and avoid many problems with interfaces, but again that's a topic of debate and some may argue very strongly against that, but some applications may work well.

I understand there are still many open questions,but that's what the core issues with OOP is.  We need align the principles as per our applications needs.  Sometimes it works great, most other times, we need to adapt a deviate a little bit.

Que1: It completely depends on the requirements of the application weather function completely depends on member fields or not. In your program, it may be feasible but not always! For example assume you have a class 'Student' which gives the information of the student with the specified id. For that you can either pass id in the constructor or set via property of via function. In this example it will be good to pass id via constructor. But assume you have a class 'StudentList' and with the function to return student with the given id. Then it will not be good to pass id via constructor because you are dealing with the student list and an id of one student cannot be the property of student list. Of course you can create a property 'CurrentStudentID' but for this you need an extra property and you need to set that property every time you need to get student info of the given id. AND REMEMBER student id is not the behavior of StudentList. You need to follow 'single responsibility principle' which states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.

Que2: No, you don't need to pass parameters. Define an abstract Strategy class with variables (Private or Protected) required for applying strategy (NOT any concrete class specific variables) and pass the individual concrete class variable (Private probably) via their constructors. 

How helpful are interfaces which defines only Properties and No Methods? Should I define an Interface which has all the properites, and every class which needs it must implement it and process information.
-Suppose you are creating MVC application, then it may be good idea to define interface with properties only as model is just business objects with data to be displayed in the view. And again it depends on your requirements. In your example ComputeValue can be a method of interface as every concrete class must have it. Define properties in the interface only if it is useful in every concrete class. If you are defining property which is useful in only one concrete class, then it is not good practice to have it in interface. 

If interface changes every class which implements also breaks: breaking rule Open Close principle. How do we overcome this?
-I am not sure what do you mean by interface change. If it means addition of new method in interface, then yes every class (at least an abstract class) also breaks and needs modification. If you mean change in parameters of function of interface, then that means you haven't done enough research while doing class design (before code starts). But even with enough research and proper design, there may be the case where we may need to change interface and hence need to change concrete class. So, to get rid of such scenario, we need to follow some principles. This page can be helpful for you.

Thanks,

Pradip