EMEA PUG 2017 presentations

Yes, I know Peter had a presentation where he showed the singelton implementation. I hoped it could bring some light to me :-)

I guess it was answered, as [mention:581c41ccec94499580f4ad95d78f8d35:e9ed411860ed4f2ba0265705b8793d05] is advancing on the solution they are searching.

Good luck on that!

DILLY! DILLY!  

Sorry, forgot to thanx :-) thanx Mike...

Using the Singleton is a bad idea...

stackoverflow.com/.../why-is-singleton-considered-an-anti-pattern

And yet, it's unanswered...

There is no word on EMEAPUG2017 releasing...

Apologies - we are having some technical issues that we will resolve as soon as we can.

Good news - most of the slides are now available on pugchallenge.eu/.../session-details (there's a 'download files' link). A few are missing, but we'll try and fill up the gaps as soon as we can.

Thanks goo for raising issue was also looking forward material.

So far unless I missed something there's no material available from the workshop session as the number of seat was limited it could be good to get some more insight from material distributed there (if any).

Denis

We don't tend to publish materials from the workshops on the basis that in general they make very little sense without the context of the workshop itself.

You are right [mention:77cbb45621a246f9a1a1f2f378e535b1:e9ed411860ed4f2ba0265705b8793d05] as I've tryed some of them and had hard time to get it trough.

Neverteless, thay are really good to give us, (who are unknow to the subject) some clues and some kind of context, and in case of me being non english native, the expresions and correct phrases thay allows me to make the correct questions on researching/googling the subject.  Most of the time the order of ideas can come out more naturally.

You could try contacting the workshop presenters too.

True, that person was on holiday though ;)

Had a short look at advanced_ooabl_patterns.pdf. Much in this document is questionable. I would not trust on the authority of the speakers and google around a bit for criticism before using this "advanced" stuff (most of it is needless complicating).

It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity.

Dijkstra (1996) "The next fifty years" (EWD 1243a).

Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.

Dijkstra (1984) On the nature of Computing Science (EWD896).

Peter,

My previous reaction has not been put on the forum for to me unknown reasons. Moderator?

 I had a short look at www.pugchallenge.eu/.../progress---advanced_ooabl_patterns.pdf since I'm doing a massive refactoring job ( > 9 months fulltime work) on an openedge oo backend.

 I find a least a part of the recommendations examples of bad practice. For example "Use inheritance for common or shared behaviour". Part of my refactoring consist of removing inheritance / subtype polymorphism from the application I'm working on. I sent messages before about it: community.progress.com/.../34837 , there are more threads where I said something about it. Even the GOF book says " favor composition over inheritance". Gus has criticism also, I would love him to write a couple of sentences on the subject. But in the meantime you could ask him when you're interested.

 About your other advises I would recommend to look for criticism on the internet and think it all out before adding needless complexity which will be regretted lateron when maintenance is necessary. I have a hell of a job removing needless complexity / "recommended practices" now.

-------------------------------------------------------------------------------------------------------------------------------------------------------------

Gus Bjorklund <xxxx@xxxx.com>	8/20/15
to Peter, PEG

Used properly, inheritance is useful and makes it easy to do certain things that would be a pain to implement using composition.

It's when it's abused and misused vs composition that it's harmful.

It would be helpful if a presentation like yours would explain both strategies, when you would use one and when the other. I only read "Use inheritance for common or shared behaviour", and that's harmful when followed. Until now I never found a need / justification for inheritance. The much named is-a relation is not a real good reason in at least a lot of cases as this relation can / should be able to change over time (during maintenance). All this is discussed by others already enough on the internet.

 The gof book is not a bible to me btw. So this "favour" is not an advise I follow.

This saying has always seemed a bit strange to me since inheritance and composition exist to represent two different relationships, so the issue is to understand what those relationships are and use the correct one for the current circumstance.

I already mentioned the is-a relation for inheritance being static. Your needs may change over time, I like to build flexible, call it agile ;-) (in the right sense). Edit: Also see the message about https://en.wikipedia.org/wiki/Circle-ellipse_problem

Shared / global vars were well known to make things easy also in the past. When you inherit, you strongly couple child to parent class. That is very easy; you for instance do not have to instantiate the parent and you do not have to reference that class when using it's protected/public members. But you get all the problems of strong coupling with that ease. I'm not going to repeat those: google for them if you're not sure. You can strive for referentially transparent code also. Members that get all their dependencies injected (parameter objects are handy) and where possible leave no state behind. Such code is reusable and it's simple to move. There is a distinction to be made between simple (in the sense of disentangled) and easy. www.infoq.com/.../Simple-Made-Easy

------------------------------

Used properly, inheritance is useful and makes it easy to do certain things that would be a pain to implement using composition.

It's when it's abused and misused vs composition that it's harmful.

Many discussions on the internet about those relationships. F.e. about the circle-ellipse problem en.wikipedia.org/.../Circle-ellipse_problem (you've discussed that before on the peg). Mathematically a circle is-a ellipse. Proposed solution in this wiki entry: "Drop all inheritance relationships [..] This solves the problem at a stroke." Discussion f.e.: softwareengineering.stackexchange.com/.../can-the-circle-ellipse-problem-be-solved-by-reversing-the-relationship .

  More in common here Szyperski (PhD CS, Principal Group Software Engineering Manager at Microsoft) argues "why we think that abolishing inheritance may be worthwhile". http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=50F27FE883E271E69F164874BF621AA7?doi=10.1.1.149.9148&rep=rep1&type=pdf . There is an alinea called "Inheritance Considered Harmful" (same title as the paper that Gus wanted to write).

  But Judge & de Pijper recommend otherwise, not argumented at all however ....

-------------------------------------------------------------------

This saying has always seemed a bit strange to me since inheritance and composition exist to represent two different relationships, so the issue is to understand what those relationships are and use the correct one for the current circumstance.

I still don't get the issue ... inheritance and composition are for different problems.  If one is clear about that, one or the other (or neither) will be appropriate for a given problem and the other one won't.  Strong coupling is appropriate in inheritance because the two are different aspects of the same thing.

WRT the circle-ellipse question - all the answers I read got it wrong.

There is a common ancestor for both, but they don't stack.

Ie, you can't do Ellipse->Circle or Circle->Ellipse

The inheritance should be:

RoundObject (x, y) -> Circle (radius)

RoundObject (x, y) -> Ellipse(x, y)

Make the RoundObject constructor like so:

Constructor PROTECTED RoundObject (x, y)

Make the RoundObject "x, y" properties protected and map RoundObject:X, RoundObject:Y to Radius in Circle and X, Y in Ellipse, and the problem is solved.

The circle-ellipse problem is well known in CS Tim, sorry. And how would you debunk Szyperski 's citeseerx.ist.psu.edu/.../download;jsessionid=50F27FE883E271E69F164874BF621AA7  in ten minutes again for the readers?

Just carefully read Szyperski's article then Thomas, why this whole inheritance is to be avoided. It says f.e. "nothing is wrong with inheritance as such. If an object inherits state and methods from another one, it may add additional things as long as it leaves all the inherited stuff alone. This means that no methods must be changed and that additional methods must not change the internal state of the base object. Unfortunately, this is not how inheritance is viewed and how it is being used currently. The ability to replace entire methods and to manipulate the inherited state is viewed as an essential ingredient of inheritance." So is-a? While the parent is used as mutable? My time is limited, I'm not going to try to explain it all and the article is clear / readable and contains enough references, as should be in credible / scientific papers. 

By accident read this comment by that Lahman which writings you recommended, Thomas ( from comp.object.narkive.com/.../inheritance-and-function-reuse-why-is-it-bad ):

---------------------------------------------------------------------

H. S. Lahman 14 years ago

PermalinkRaw Message Responding to Willis...

Post by Grumpy Willis

I'm interested to learn why use of inherited functions are frowned upon, and

indeed why it is allowed in a language at all if it *is* frowned upon.

----------

It is frowned upon for a couple of reasons. If subclasses can override

the behaviors, then it opens a Pandora's Box of opportunities for

foot-shooting. While the problem is greatly reduced if overrides are

not allowed, it still exists. Basically the problem is that if the tree

is reorganized, it is possible to break existing clients of superclasses

because the concrete behavior they expected is no longer provided.

Another reason is that it complicates maintenance of generalizations.

The OO is-a relation is already difficult to modify because it is a

static structure and a client accessing a superclass depends on the

structure of the /whole/ tree. By adding implementation inheritance one

complicates making safe updates. In effect one adds another dimension

(the others being interface and data inheritance) that must be

synchronized during maintenance. In particular, such trees are

especially prone to LSP violations.

As far as why it is allowed in languages, the justification is basically

that for why C++ even exists. B-) Having the features allows the

developer more direct control over the solution, albeit at the price of

substantially increased fragility.

[Note that the OOPLs have gotten other things not quite right as well

historically, such as directly mapping knowledge responsibilities for

memory storage types.]

*************

There is nothing wrong with me that could

not be cured by a capful of Drano.

H. S. Lahman

@Thomas

Furthermore "We will talk about what implementation inheritance is and why MBD does not support it in chapter 12" (Model-Based Development: Applications By H.S. Lahman)

 I'm not posting all this just to stir things up. I see a problem that is not visibly taken serious at all, first and most important by those that influence / instruct devs.

For the record, Mr. Lahman responds:

That missive wasn't from one of my more articulate moments. I suspect that in the context I was arguing against implementation inheritance (i.e., a subclass provides an implementation of a behavior that overrides a different implementation of that behavior that is already defined in its superclass). That tends to be a maintenance nightmare. Unfortunately, it is supported by many OOPLs.

However, OOA/D generalization is a quite different beast. It is actually a variation on polymorphism (i.e., inclusion polymorphism). The superclass defines a contract for a behavior, but each subclass can provide a unique implementation of the behavior. Thus the superclass defines What the behavior is, but not How it is implemented, so there is exactly one implementation of How the behavior is implemented for each subclass. That is a pretty harmless way of providing behavior generalization since the only implementation in the inheritance limb is tied solely to the specific subclass.

FWIW, I have never been keen on referring to OO behavior generalization as "behavior inheritance". The only thing that is being inherited is the interface and semantics of the behavior; only leaf subclasses provide actual implementations of the behavior. Note that this is quite different than data inheritance in generalization, where the data implementation is defined in the superclass and cannot be overridden by any subclass. IOW, subclasses only provide values for attributes, not the storage.

I do not see what this comment of Lahman reacts upon (the "missive" he names in the first sentence). I cannot google it either. It is not clear to me what you are trying to say with this, Thomas. In this text also Lahman is railing against implementation inheritance as it is commonly used. With overrides etc. Isn't it? And that is what my criticism is about also. The Szyperski article is a lot clearer I find.

Concerning the active record pattern etc in the advanced ooabl pdf maybe (only had a short look) http://rom-rb.org/4.0/learn/ can inspire for practical solutions. Links are provided to articles (even from Fowler) that state some problems.  Erik Meijer (again: this is a "widely recognized" great computerscientist who btw in one of his presentations  calls the design patterns book crap :-) and Gavin Bierman wrote about O/R mappers here: queue.acm.org/detail.cfm .