Python: A dict, Pandas DataFrame, or NumPy array is NOT a specification of services. Wrap them in a class with clear responsibilities, and methods for specific VALUE-ADDING services for consumption by clients via a pure abstract class as interface.

Icon class
icon_class
fab fa-python
icon_class_computed
fab fa-python
Note kind
Policy level
Keywords

Just because a Python forum posting or online article shows "how to use" a dict and the capabilities of a dict does NOT mean that you should only use dict everywhere directly in actual applications!

That's not software engineering. That's not systems thinking!

Such forum postings and articles, useful as they may be, should NOT be interpreted as "a guide how to use [XYZ] capability in a robust application with an actual software architecture". They are mostly about the language capability only.

The same applies to Pandas DataFrames, NumPy arrays, and any other lower level data structure or container.

At least wrap them in a class that has clear responsibilities, and use value-adding methods that leverage (under the hood) specific data structures and specific data container mechanisms as a specific implementation choice.

Even better, use a pure abstract class as an interface, and fully decouple the client's interaction with specific implementations using public service operations (abstract methods) with concrete implementations in methods of classes that implement the interfaces. Nearly every single OO Design Pattern relies on it.

A dict or DataFrame can be used for nearly anything; An interface/class has a clearly documented specific purpose!

Relates to
Related notes
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)