Geek Answers Handbook

OOP, class / object overflow

What is a good indicator in order to know when a class is poorly designed or even necessary. In other words, when to write a class, and when not -.

+4
source share
5 answers

SOLID can help if the class is poorly designed, but it will not help answer a question like "Is object-oriented programming the best approach to this problem?"

People did a very good job of programming for mathematics and science before object-oriented programming came into fashion. If your problem falls into these categories, perhaps object-oriented programming is not for you.

Objects are state and behavior together; they, as a rule, are mapped to objects of the object area to each other. If this is not the case for your problem, then maybe object-oriented programming is not for you.

If you do not know an object-oriented language well, perhaps object-oriented programming is not for you.

If your organization does not know and cannot support object-oriented solutions, perhaps object-oriented programming is not for you.

+11
source

Many people will say that “MODERN Principles” is a good guide for class design.

There are many articles / podcasts about SOLID principles, just do a quick search. Here's a good start:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

+6
source

instead of listing a bunch of don't-do-this rules for recognizing a poorly designed class, it’s easier and more efficient to list a few rules that define a good class:

  • a class is a collection of related states and behaviors
  • behavior should use only state and method parameters
  • if you think of a state as a relation (that is, as columns in a relational database table), the object identifier (pointer) is the main (synthetic) key, and the state contains non-key attributes. Is the object a third normal form? If not, divide it into two or more objects.
  • - is the life cycle of the facility completed? In other words, do you have enough methods to distract the object from creation through use and finally destroy / destroy? If not, what methods (or states / transitions) are missing?
  • Is this all the state used by at least one method? If not, does it provide descriptive information useful to the user of the object? If the answer to both of them is no, then get rid of the extraneous state.

if the problem you are trying to solve does not require a state, you do not need an object.

+4
source

In addition to SOLID principles, take a look at Code Smells. They were mentioned first (IIRC) in Martin Fowler's book "Refactoring", which is well read.

Code smells are usually applicable to OO, as well as to procedural development to some extent, including things like “Shotgun Surgery”, where for the entire code base modification, changes are required to change one small thing, or “Random smell of the case”, where giant switch cases control the flow of your application.

The best thing about Refactoring (the book) is that it recommends ways to correct code odors and takes a pragmatic view of them - they are just like real smells - you can live with some of them, but not with others.

+2
source

One of the best sensors I've ever seen for poor design overall is an expert assessment.

+2
source

More articles:


All Articles