Iced Tea in Crete 2012:To OO or not to OO

From WikiEducator
Jump to: navigation, search
To OO or not to OO
Convenor: Yesper Udby
Participants:
  • James S.
  • Henri
  • George
  • Alexander
  • Elisabeth
  • Ant
  • James G.
  • Richard
  • Brian
  • Kerstin
  • Michael
Summary:

Different paradigms for different problems Even in OO there is a compositional style vs an inheritance style. Then you have functional paradigms too.

No body uses big architecture docs anymore but most do sequence and class diagrams ad hoc. Some tools that allow reverse engineering and round trip.

http://www.architexa.com/ http://www.objectaid.com/   

Some Discussion Points

  • 15 years ago, when everybody was still doing waterfall, we started with uses cases or requirements, then did an analysis and came up with a class architecture which was captured in diagrams (such as UML). Classes used to have both data and behavior.
  • Nowadays we have a service layer were the behavior is located. This is the Service Oriented world, where classes don't really have a lot of behavior any more.
  • Why was Service Oriented Architecture invented? What problem was it trying to solve?
  • Context dependency of objects: Objects/Classes for the same type may have different requirements depending on the use. A container (large metal container that goes on ships) may sometimes be looked at just in terms of how many containers there are, sometimes it may be important to know what is inside and if refrigeration is required, sometimes just the type of container. This means that depending on the context, an object may have different methods/data during its life. Sometimes, different parts of the lifecycle of an object (such as a container) are handled by different businesses whose systems are not even interconnected.
  • Is OO maybe more theoretical than practical? - OO can make it easier to talk about a problem.
  • data objects could have changing methods as well as changing data, depending on the context they are being used in; data and methods change asynchronously, i.e. you don't necessarily change the methods every time you update the data; often data changes much more often;
  • should we still share code via inheritance? Or should we just use helper classes that do the common stuff? Or inject collaborators? Or interfaces, which define what the object can do?
  • How does OO compare to functional programming in languages such as Scala?
  • Can everybody even twist their head around OO?
Recommendations:

Recommendations go here

  • ...
  • ...