What should an object look like?

Question

Hi All,

I am constantly debating how best to create my classes.

By this I mean why dont we always create a class that Implements INotifyPropertyChanged and IDataErrorInfo so that "if" we want to we can bind directly in our forms, and why dont we always decorate them with the attributes so that if we want to we can use the class in WCF?

I mean apart from the obvious extra code, and more testing wont this give us better flexibility?

I always hear - 'create once' and use 'everywhere' but I am also in tune with 'YAGNI' (you aint going to need it).

I guess my question here is has the idea of 'a business class' than can be re-used dead? and do we say 'create the most basic' that works for now, and build upon it when required?

R

Answer 1

I think it's usually better to make your classes more focused to a small set of specific tasks, rather than creating objects that can be used in a variety of scenarios. For example, you might have data-layer objects that have all the data-layer specific attributes/behaviors, presentation layer objects with all the presentation layer stuff, and service layer objects, etc.

If you make your classes too "all-powerful" you'll end up creating a lot of dependencies in your different layers, which make it much more difficult to change in the future. Do a google search for "Single Responsibility Principle" - it's one of the "SOLID" principles of OO.

Answer 2

I create many, many classes that are very far removed from the UI. Implementing those interfaces every time would be a heavy burder, with minimal reward.

Answer 3

First off, programmers are lazy, our modivation is to automate boring tasks. (no I'm not being negative) We generally write classes to serve a particular purpose which dicates what sort of extra bits go into it. You are asking the basic question that aspect oriented programming attempts to answer. Is my class a serivce? Is my class a data container? Is my class observable? These are aspects your class can be all of these things depending on usage. Or it may only ever be one of them.

Answer 4

If you do that, where do you draw the line? Are you going to make all your classes Exceptions because some day you might want to throw them from somewhere? Are you going to make them all serializable?

Another way you can think about it is that the language designers already made that decision for you - all classes automatically inherit from Object, which contains everything a "general" object needs.

Finally, don't confuse code reuse with writing unnecessary code. In general, you should only write the code that you need right now, but design it so that it's easy to use/change in the future.