Geek Answers Handbook

OO Software Development Principles

I am a big fan of software development principles such as SOLID and DRY . What other principles exist for OO software development?

Note. I'm not looking for answers, such as “comment on your code,” but instead looking for OO principles, such as those discussed by Uncle Bob .

+4
source share
9 answers

A fairly complete list from Wikipedia:

http://en.wikipedia.org/wiki/List_of_software_development_philosophies

  • Flexible software development.
  • Agile Unified Process (AUP)
  • Behavior-Driven Development (BDD)
  • Big Design Up Front (BDUF)
  • Brooks Law
  • Cathedral and Bazaar
  • Code and Fix
  • Design Engineering Methodology (CDM)
  • Cowboy Coding
  • Crystal clear
  • Design Development (D3)
  • Do not repeat yourself (DRY) or once and only once (OAOO), Single Point of Truth (SPoT)
  • Dynamic System Development Method (DSDM)
  • Extreme Programming (XP)
  • Function development.
  • Hollywood principle
  • Iterative and incremental development
  • Collaborative application development, as well as JAD or Collaborative Application Development.
  • Kaizen
  • Kanban
  • KISS Principle (Keep It Simple, Stupid)
  • Software development for Lean.
  • Microsoft Solutions Framework (MSF)
  • Model Architecture (MDA)
  • Open source
  • Open a single process
  • Quick and dirty
  • Rational Unified Process (RUP)
  • Scrum
  • Intelligent (agile)
  • Separation of Problems (SoC)
  • Service Oriented Modeling
  • Software skill
  • System security software
  • Spiral model
  • Testing Development (TDD)
  • Unified Process (UP)
  • V-model
  • Waterfall model
  • Model with wheel and spokes.
  • Worse - better (New Jersey style, unlike the MIT approach).
  • Xtreme
  • You won’t need it (YAGNI)
  • Zero infinity
+6
source

High Cohesion - How focused are the responsibilities of the modules you are developing.

Low Coupling - The degree to which modules rely on other modules.

+4
source

KISS

+2
source

Choosing a composition over inheritance is one thing.

Many people, especially those new to OO, will begin to extend classes when all they really need is to use composition. Indeed, if you must ask yourself, is the new class B a class A? If not, you should not spread.

For example, let's say I have a Person Class, a Car class, and I would like to create a new class with a DrivenCar class. A naive implementation would be to say (let it pretend we got multiple inheritance)

 class DrivenCar extends Person, Car { ... }

Is DrivenCar a Person Type? No, therefore, he should not expand the Personality. Is DrivenCar a car? yes, so it makes sense to expand

Using composition, the implication will look like

 class DrivenCar extends Car { private Person driver; }
+2
source

GRASP . Yes, they seem pretty trivial. More like distillation to the basic qualities that other, more attractive samples demonstrate.

+2
source

YAGNI

+1
source

interface. Most design patterns are based on separation of interface and implementation.

0
source

When your API grows, use an abstract class instead of an interface. Adding a new method to the Interface requires changing ALL classes that implement it.

0
source

Check out this article on software development guidelines .

This guy explains the key design principles that help create easy-to-repair and extensible software in a simple way, using a practical example. The article looks interesting and useful, you never regret reading it.

0
source

More articles:


All Articles