On Thu, Jul 19, 2018 at 02:01:07PM +0000, Marcus Daniels wrote:
> "Like with the Great Man Theory, the actual causes of any phenomena in a
> complex and complicated system like Xerox Parc (embedded in culture, society,
> psychology, physiology, biology, chemistry, etc.) are multifarious and
> occult."
>
>
> Assuming there even was a Great Idea to go with a Great Man. For starters..
>
>
> https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
>
> http://www.stlport.org/resources/StepanovUSA.html
>
> http://wiki.c2.com/?ArgumentsAgainstOop
> https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit
>
>
All these seem to be arguments against what I call OO purism. An OO
purist tends to see things in terms of UML diagrams, and a 1-1
relationship between the UML diagram and the code. This leads to
limited flexibility (ie code fragility), and to be quite frank, at
times confusing code.
For me the techniques of OOP (by which I mean attaching methods to a
collection of data, and only that) are simply tools in a
toolbox, amongst many others.
Inheritance is great for code reusability, composition much
less so (requiring much more error prone plumbing code). The isa
versus hasa distinction needn't apply, but can be useful for rasoning
or modelling, but not always.
(Dynamic) Polymorphism can be useful for
containers of similarly behaving things that have distinctly different
data structures. I tend to use generic programming and duck typing
otherwise.
Encapsulation is extremely important to maintain invariants
- where the state of two fields depend on each other, they should be
encapsulated to prevent their values getting out of sync. Otherwise,
it is generally more useful to expose members directly as public (a
bit more thought is required with APIs, of course). And don't get me
started on getters/setters. If an attribute has both a getter and
setter (particularly trivial ones), it is a code smell that it really
should be a public attribute. I have seen encapsulation taken to such
extremes that code becomes difficult to understand and debug.
And as for patterns, I have sympathy for the person who said that
patterns make up for deficiencies in a language. The classic example
might be the Singleton pattern making up for an absence of global
variables in Java. I haven't read the GoF book, but have seen some
disasterous applications of patterns to code, that obscure and
complexify things unnecessarily. Nevertheless, I do use some patterns
(that I don't believe are in the GoF book), particularly for
multithreading (cf active object), or my favourite the lazy
instantiator:
inline Foo& foo()
{
static Foo f;
return f;
}
This pattern (which is actually a kind of Singleton) is required to
get around C++'s link time ordering problem. You must make sure foo()
is called at least once before any multithreading is started though,
perhaps by setting a static variable in the main.cc file, otherwise
you end up with a race condition.
--
----------------------------------------------------------------------------
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpco...@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au
----------------------------------------------------------------------------
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
