[jira] [Comment Edited] (LOG4J2-3100) log4j2 lots of final class, forbid extend class, why log4j allow extend class but log4j2 not?

["Gary D. Gregory (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17353734#comment-17353734 ] 

Gary D. Gregory edited comment on LOG4J2-3100 at 5/29/21, 11:31 AM:
--------------------------------------------------------------------

I agree with [~vy].

It's better to provide API stability IMO.

As soon as you allow a type to be extended you are locked in to provide compatibility for not just public method but also protected methods and variables.

Recall that unless your design use case defines a true "is a kind of" relationship for a subtype, subclassing becomes a reuse convenience hack where composition would be appropriate. 


was (Author: garydgregory):
I agree with [~vy].

It's better to provide API stability IMO.

As soon as you allow a type to be extended you are locked in to provide compatibility for not just public method but also protected methods and variables.

Recall that unless your design use case defines a true "is a kind of" relationship for subtype, subclassing becomes a reuse convenience hack where composition would be appropriate. 

> log4j2 lots of final class,  forbid extend class,  why log4j allow extend class but log4j2 not?
> -----------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-3100
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3100
>             Project: Log4j 2
>          Issue Type: Question
>            Reporter: hzwwe
>            Assignee: Volkan Yazici
>            Priority: Trivial
>
> RollingFileAppender
> PatternLayout
> etc....
> all are final class



--
This message was sent by Atlassian Jira
(v8.3.4#803005)