Good Enough Object

1. Good Enough Object a.f.hampe 2012.09.19

2. Super Sekret Agenda • Learn Perl’s Object Model • Learn Some Basic OO Ideas • ISA from HASA • What is inheritance • Cool Stuff

3. Things out of scope • Three Interesting Spaces • Mouse • Moose • Inside Out ??? • yourCultHere • Procedural v. OO v. Functional

4. There are two vectors to consider • The Code side • scripts => libs => objects • The Variable side • vars => structs => objects • Data or Code? who’s on first? • We shall assume folks know scripting well enough.

5. The Basic Lib Issue • And this does not take into account the functions. • It does raise a useful question -- how should the functions be imported? How should they be grouped? • In short, should we break this library into little groups of functions? Or into their own libs? • That is a common problem.

6. Scary Thought Time • What one exports others import. • Best to not export by default • Saves on name space collision • In ‘C’ code macro’s and #define work because the pre-processor before compiling • Constants are subs in perl. • Why export a variable?

7. Rethinking the constant game • Why yes, we still have N+1 sub calls in the method model. So it is not a great win in itself. • As a general rule of thumb I dislike exporting variables and specifically constants. • It gets crazier if we export with AUTOLOAD() on, and then re-exporting the symbol up the stack. What if the caller also imported from the same source?

8. ReExporting up the stack? • Module A is imported into B and C • B exports to C AF_INET6 • C imported AF_INET6 from A • Which error message about redefining will occur at this time? • How can you turn only that warning off?

9. The Shorter Exporter • Great for single function libs • It is ok if one has to start setting up export tags • It gets crazy if one exports constants and variables • It gets out of hand the further from the script that is executed. • It hides dependencies.

10. A Small Object Foo::Bar • Notice, no exporting. • No lists to manage. • No worrying about what the caller does with their name space issues. • Notice, it does not require that we have a data model with data stuff! It just issues a function/method

11. Mixing In A Module In A Script • Always a nice way to play with an idea. • It can even be all the code! no nasty modules. • No code re-use by others, but, hey...

12. The Basic Vars of Perl • There are only four of them • scalar ( could be a ref ) • list • hash ( aka Associative Array ) • packed data (cf pack and unpack) • There is no varchar, int, float, etc • Upon these, structs && objects bloom

13. Struct v. Object • Just use struct if any of the natural data types, including HoH or AoH, work well enough. • Never decorate what is just data • Solve the data model first before deciding on object v. struct • Will the object simplify the documentation of the work at hand?

14. That documenting thing you do • The POD is documentation • You are probably doing it wrong if they needed • the Header File or Code to understand the documentation • a native guide to solve the inheritance chain or the lost function of foo_bar(). • you to maintain it!

15. A simple enough struct documentation • One should explain the variables, in this case we have a ‘$ytag’ as the key to the hash reference of four keys. • I use the generic expressions ‘string’ and ‘mac_addr’ to denote that we know no more than that the ssn will be some alpha-numeric, and the macs, are mac addresses and will conform to that standard.

16. Indicating a Hasa Requirement • Here we need two objects passed to the constructor. • In the long run, let them create them and pass them. This way the current object focuses on using the object, not on how they are constructed. • This object, has a “Hasa” relationship with it’s contained objects.

17. The Shorter OO Perl • A reference is blessed into a ‘package’ name space. • hash refs are a good enough basic data model • The inheritance chain defines what methods are local to this package, and which are in the super class. { document your inheritance! } • nice code reuse • Hasa may require ‘adapter’ methods if you want to share the object externally. • Can just use the direct access to the ‘hash’ to do what needs to be done. Do not need accessor/mutator methods. ( I hate setter/getter rhetoric! )

18. A simple Immutable Object • All values are passed in at create time. • We have only the three accessors. • They find their data at the named slot in the first argument passed in “@_” -- the majik perl varg. • About as close to a decorated struct as we want.

19. Subclass of an Immutable • The ‘use base’ pragma tells us we are a subclass, and sets @ISA -- since this class isa Foo::WorkObject, so has all of the parent’s methods, plus any that we add locally. • I used this trick for two ‘auto_populate’ apps, where the second one needed a slightly different syntax. • This is a win for object over struct.

20. SubSubClass with Super • Note, the sub-subclass overrides the ‘filter’ method that it would have inherited from it’s super class, Foo::WorkObject. • SUPER allows us to call filter() in the parent before we do our thing with it! • Note: you do not need to call SUPER to get methods that you inherited.

21. Simple Adapter Pattern • In the node_get() there is no reason to use the NodeGet() adapter, but.... • The node_get() adds the value add, that undef means that there is no node. • We rethrow any unresolved errors, or return the data. • We do not know if this is a real opsdb or test one.

22. Summary • A blessed hash reference is a good enough data structure to build on. • Sometimes they just return structs • Hasa v. ISA is a fun debate • Build simple things to do simple things often advocates a Hasa approach to the solution. • JeffFoxWorthy Jokes in an inheritance chain, BAD. • Sometimes you have to reach up to the parent class and get it’s work before doing your own. • Any reasonable questions?

23. Any Unreasonable Questions • You still like inside-out objects? • My Mouse/Moose Conflict can ONLY be ONE! • insert joke here.