3 ms·

One very important issue in OOP is packaging together variable names. You can see the issue by looking at this atrocious function signature from the Python Pand

One very important issue in OOP is packaging together variable names. You can see the issue by looking at this atrocious function signature from the Python Pandas library: > pandas.read_csv(filepath_or_buffer, *, sep=<no_default>, delimiter=None, header='infer', names=<no_default>, index_col=None, usecols=None, dtype=None, engine=None, converters=None, true_values=None, false_values=None, skipinitialspace=False, skiprows=None, skipfooter=0, nrows=None, na_values=None, keep_default_na=True, na_filter=True, verbose=<no_default>, skip_blank_lines=True, parse_dates=None, infer_datetime_format=<no_default>, keep_date_col=<no_default>, date_parser=<no_default>, date_format=None, dayfirst=False, cache_dates=True, iterator=False, chunksize=None, compression='infer', thousands=None, decimal='.', lineterminator=None, quotechar='"', quoting=0, doublequote=True, escapechar=None, comment=None, encoding=None, encoding_errors='strict', dialect=None, on_bad_lines='error', delim_whitespace=<no_default>, low_memory=True, memory_map=False, float_precision=None, storage_options=None, dtype_backend=<no_default>) An OOP approach would define a Reader object that has many methods supporting various configuration options (setSkipRows(..), setNaFilter(...), etc), perhaps using a fluent style. Finally you call a read() method that returns the DataFrame.

coliveira 2y ago
While this signature really looks atrocious, it doesn't make the programmer experience bad at all, because all these parameters have default values. So it basically works as an interface with many options with convenient standard values and you can change only what you need.
hombre_fatal 2y ago
This seems like a trivial example though. read_csv(options: Options) All you've shown is that Options has a lot of configurability, but you'd have the same problem if you posted the whole class with all of its fluent API methods; it would be even more characters. Also, you can use built-in control flow logic to modify options before passing them into the function rather than depend on a developer to implement a fluent API for every class. But this isn't an example of FP vs OOP. Just replace `read_csv(options)` with `constructor(options)`.
lucianbr 2y ago
> a Reader object that has many methods supporting various configuration options (setSkipRows(..), setNaFilter(...), etc), perhaps using a fluent style I don't understand what that would bring as opposed to the current situation you mention, where you just call read_csv and name each parameter you want with the value you want. If anything, I'd say the builder pattern is a crutch for languages that don't have named parameters.
lyu07282 2y ago
A much better example for the issue with OOP gone wrong is the Spring framework: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html https://docs.spring.io/spring-framework/docs/current/javadoc...

coliveira 2y ago

While this signature really looks atrocious, it doesn't make the programmer experience bad at all, because all these parameters have default values. So it basically works as an interface with many options with convenient standard values and you can change only what you need.

hombre_fatal 2y ago

This seems like a trivial example though. read_csv(options: Options) All you've shown is that Options has a lot of configurability, but you'd have the same problem if you posted the whole class with all of its fluent API methods; it would be even more characters. Also, you can use built-in control flow logic to modify options before passing them into the function rather than depend on a developer to implement a fluent API for every class. But this isn't an example of FP vs OOP. Just replace `read_csv(options)` with `constructor(options)`.

lucianbr 2y ago

> a Reader object that has many methods supporting various configuration options (setSkipRows(..), setNaFilter(...), etc), perhaps using a fluent style I don't understand what that would bring as opposed to the current situation you mention, where you just call read_csv and name each parameter you want with the value you want. If anything, I'd say the builder pattern is a crutch for languages that don't have named parameters.

lyu07282 2y ago

A much better example for the issue with OOP gone wrong is the Spring framework: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html https://docs.spring.io/spring-framework/docs/current/javadoc...